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

The description adds critical context beyond the readOnlyHint annotation by warning that this endpoint returns sensitive secrets and explaining the default omission of the recovery_key field. It also discloses that setting raw: true exposes the actual key material, which is essential behavioral information for safe use.

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 three sentences, each earning its place: the first states the core function and filters, the second warns about sensitivity and appropriate usage, and the third explains the default behavior and raw flag. It is front-loaded and free of unnecessary wording.

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

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

For a 4-parameter sensitive tool with no output schema, the description covers the returned fields, filters, and the critical raw flag behavior. It provides enough context for an agent to decide when to use it and how to invoke it correctly, including the security implications.

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 documents all four parameters with descriptions, so the baseline is 3. The description adds value by explicitly naming the three filterable fields and providing extra context about the raw parameter—clarifying that it controls exposure of the actual key material and defaults to false.

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 'Retrieves BitLocker recovery key records' specifying the exact resource and action, then details the fields returned (key protector ID, drive letter, computer, domain) and filter options. This clearly distinguishes it from sibling tools like bitlocker_tpm_report by focusing specifically on recovery key material.

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 explicitly states when to use the tool ('Only use it when key retrieval is genuinely needed') and when not to ('never for routine reporting'), which is strong guidance. However, it stops short of naming specific alternative tools for routine reporting, so it does not fully satisfy the 'vs alternatives' criterion.

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, but it does not reveal additional behavioral traits such as pagination behavior, rate limits, or whether results are ordered. With annotations present, 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?

The description is two sentences, entirely focused and front-loaded. The first sentence states exactly what is retrieved, and the second sentence covers filtering. No redundant or filler 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?

Given no output schema, the description does a good job of listing the returned fields, which is essential for a report tool. It also mentions filtering options. However, it does not describe the return format (e.g., list, count, pagination) beyond the schema parameters. For a simple list tool with well-documented parameters, this is nearly 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?

Since schema description coverage is 100%, the baseline is 3. The description mentions filtering by resource_id or domain but does not add significant meaning beyond what the schema already provides for each parameter. It does highlight the two filter options, which is a minor enhancement.

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 ('Retrieves') and identifies a precise resource ('drive-level BitLocker encryption details') with a list of concrete fields. It clearly distinguishes itself from siblings like bitlocker_recovery_key_details and bitlocker_tpm_report by focusing on drive-level encryption status and supporting filtering.

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: it retrieves drive-level BitLocker details across managed computers and supports filtering by resource_id or domain. While it does not explicitly contrast with alternative tools, the field list and scope make its intended use clear. No 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 clear. The description adds that it retrieves specific TPM fields across computers, but does not disclose additional behavior like pagination behavior or permissions beyond what is implied by the read-only annotation.

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 core purpose and followed by the filtering scope. It contains zero wasteful words and is easy to parse.

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 report tool with annotations, the description covers the returned fields and filtering options. It does not explain pagination or the raw parameter, but those are documented in the schema, so the gap is minor.

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

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

Schema description coverage is 100%, so the schema fully documents all five parameters. The description only restates filtering by resource_id or domain, which adds no new semantics beyond the schema's parameter descriptions.

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 ('Retrieves') and resource ('TPM details across managed computers'), listing the fields returned. It is clearly distinct from siblings like bitlocker_recovery_key_details and bitlocker_reports_list because of the TPM focus, though it does not explicitly name alternatives.

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

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

The description mentions filtering by resource_id or domain, giving some usage context, but does not explicitly state when to use this tool versus other bitlocker-related tools or provide exclusion criteria. Usage is implied rather than explicitly directed.

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 value by specifying the exact returned information: a list of custom data type names and a boolean indicating whether any exist. This is useful behavioral context, especially given the absence of an output schema.

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

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

The description is concise: two sentences, front-loaded with the action verb 'Retrieves,' and every word adds value. It avoids repeating schema details and provides no unnecessary 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 has zero parameters, no output schema, and helpful annotations, the description fully covers what is needed: what the tool does, when to use it, and what it returns. It is a complete and self-contained description for this simple list operation.

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 baseline score is 4 per the rubric. The schema shows no properties, and the description correctly implies that no inputs are needed, so no additional parameter semantics are required.

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

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

The description clearly states the tool's function: retrieving existing custom data type names for custom fields and indicating whether any exist. This is a specific verb+resource combination that effectively distinguishes it from sibling tools like custom_column_udt_name_exists and custom_column_udt_length.

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 explicitly notes the tool is 'Useful before creating or updating custom fields,' providing clear context for when to invoke it. It does not explicitly exclude alternatives or state when not to use it, but for a simple read-only list tool this is adequate.

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 some context about the 'maximum number of characters allowed,' but does not disclose return format, error behavior, or prerequisites beyond what the schema supplies. It meets the baseline but doesn't exceed 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, compact sentence that front-loads the verb and resource. It avoids wordiness, though it is fairly terse and could optionally include a note about needing the internal column name (which is already in the schema).

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

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

The description and schema together give a clear picture for a simple read-only lookup, and the return value (maximum character count) is implied. However, there is no output schema and no mention of edge cases like missing fields or invalid table names, leaving some gaps for an agent to fully invoke 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?

Schema description coverage is 100%, so the schema fully documents both parameters with type, enum, and example. The description adds no additional parameter-level meaning, so the baseline 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 'retrieves' and clearly defines the resource: 'the maximum number of characters allowed for the user data type of a specific custom field.' This distinguishes it from sibling tools that deal with existence checks or listing data types, though it doesn't explicitly name them.

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

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

The description implies when to use the tool (for a specific custom field's type length), but provides no explicit guidance on when to use it over alternatives like custom_column_udt_name_exists or custom_field_metadata_list. There are no exclusions or alternative recommendations.

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 known. The description adds that this is a pure existence check, but does not disclose any additional behavioral traits such as return format, case sensitivity, or partial matching behavior. No contradiction.

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

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

One sentence, 18 words, front-loaded with the action. Every word earns its place; no fluff or repetition.

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 1-parameter predicate tool with read-only annotations, the description is adequate. It states what it checks and the target resource. It does not mention the return value, but the tool name and description strongly imply a boolean result; given the simplicity, this is acceptable.

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 single parameter udtName is fully described in the schema (100% coverage), with the description 'The name of the custom data type to check for existence.' The tool description adds no extra parameter semantics beyond this, so baseline 3 applies.

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

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

The description uses a specific verb ('Checks whether') and clearly identifies the resource (custom user data type name existence). It distinguishes itself from sibling tools like custom_column_data_types_list (which lists types) and custom_column_udt_length (which returns length) by focusing on existence checking.

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

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

The description implies the tool is for verifying existence of a custom data type name before other operations, but it does not explicitly state when to use it vs alternatives or mention any exclusions. The context is clear from the phrasing 'is already defined in the system.'

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by enumerating the returned metadata fields and clarifying that it is linked to a specific computer. However, it does not disclose potential pitfalls like pagination, authorization, or error behavior, so the added value beyond annotations is moderate.

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 long, front-loaded with the primary function, and every clause adds value. It includes concrete examples (COL301) and a clear downstream application without any filler. This is a model of concise, informative tool documentation.

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 metadata retrieval tool with one parameter and full schema coverage, the description is nearly complete. It explains what data will be returned and why the tool matters for downstream operations. The absence of an output schema is mitigated by the explicit list of fields. It lacks only minor details like error conditions or pagination, which are less critical given the tool's narrow, read-only scope.

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 provides 100% coverage for the single parameter resourceId, including a description that it is the numeric resource_id from som_computers_list. The tool description does not add further parameter-specific details beyond referring to a 'specific computer', so the schema carries the heavy lifting. 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 the specific verb 'Retrieves' and identifies the exact resource: 'custom field metadata linked to a specific computer'. It lists the key data fields (display name, actual column name, data type, etc.), making the tool's function unmistakable. It also distinguishes itself from sibling tools by explaining its role in discovering actualColumnName for modify/remove 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 explicitly states when to use the tool: 'Use this to discover the actualColumnName needed by the custom column modify/remove tools.' This provides clear context for the tool's primary purpose. It does not mention alternatives or exclusions, but the explicit use case is strong enough for a 4.

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 agent knows it is a safe read operation. The description adds value by specifying the exact scope of the retrieved data (owner, location, product number, shipping/expiry dates, notes, search tag, user-defined fields), which goes beyond the annotation hints. No contradictions; the 'Retrieves' verb aligns with read-only behavior.

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

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

The description is a single, front-loaded sentence that immediately states the verb and resource. It includes examples in parentheses without excess verbosity. Every word contributes to understanding the tool's function. No filler or redundant information.

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

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

Given the tool's low complexity (one parameter, no output schema, strong annotations), the description is reasonably complete. It covers what the tool retrieves and the resource type. It could optionally mention that the resource can be a computer or software, but this is already in the schema description. Overall, sufficient context for an agent without being verbose.

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 schema description for resourceId is detailed, explaining it expects either a computer resource_id or a software_id. The tool description does not add any additional parameter semantics beyond 'specific resource', so with high schema coverage a baseline 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 'Retrieves' and clearly identifies the resource: 'custom field values linked to a specific resource'. It lists example fields (owner, location, product number, etc.), making it distinct from sibling tools like custom_field_metadata_list which lists metadata, and custom_column_udt_name_exists which checks UDT names. This provides unambiguous purpose and distinguishes from likely alternatives.

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

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

The description implies usage: when you need custom field values for a specific resource, such as a computer or software. It provides context by listing example field categories. However, it does not explicitly mention when not to use it or reference alternatives, but the context is clear enough for an agent to select it for retrieving field values rather than metadata or other report 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, so the safety profile is clear. The description adds context that it returns 'all' custom groups (implying no filtering and possibly large result), plus the field set and epoch millis timestamps. However, it does not discuss pagination, performance, or the behavior of the 'raw' parameter beyond what the schema already states.

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 one sentence that is information-dense without redundancy. It front-loads the action ('Retrieves') and resource ('all custom groups') and packs the field list into a single clause. 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 simple list tool with one optional parameter and no output schema, the description covers the essential return fields and their formats (e.g., epoch millis). It does not mention pagination or response envelope, but for this level of complexity the description is largely complete. Slight deduction for not specifying if all results are returned in one response or paginated.

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 fully describes the single optional 'raw' parameter (coverage 100%), so the baseline is 3. The description adds no parameter-specific meaning beyond what the schema provides, which is acceptable given the high 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 clearly states the tool retrieves all custom groups and enumerates the exact fields returned (ID, name, type, category, domain, timestamps). The verb 'retrieves' is specific, and the resource 'custom groups' distinguishes it from sibling reporting 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 usage (when you need to list custom groups) from the verb and resource, but it does not explicitly state when not to use it or mention alternatives among the many sibling list/report tools. No exclusions are provided, so guidance remains at the implied level.

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 useful context about the returned fields and filters, but does not disclose additional behaviors such as pagination limits, rate limits, or response structure. This is consistent with 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 sentences: the first describes the tool's purpose and output fields, the second lists filters. Every word contributes value; no redundancy or filler. Perfectly front-loaded and concise.

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 10 parameters, no required fields, and no output schema, the description provides a solid overview of the return fields and filter capabilities. It does not explicitly mention pagination or the 'raw' option, but those are documented in the schema, so the description is sufficiently complete for a read-only list tool.

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

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

The input schema covers 100% of parameters with detailed descriptions, so the baseline is 3. The description repeats the filter names (time period, computer, group, device type, OS platform, domain) but adds no additional meaning or constraints beyond what the schema already provides.

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

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

The description clearly states it retrieves all devices blocked across the network (Device Control Management), listing the exact fields returned (device type, vendor/product, serial number, user, computer, insert/remove times). This distinguishes it from sibling tools like dcm_device_audit_list, which likely lists all device audits rather than blocked ones.

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 for when to use this tool (when blocked device audit data is needed) and enumerates the supported filters. However, it does not explicitly state alternatives or when not to use it, which would elevate it to 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, and the description adds useful behavioral context: it explains the curated default omits legacy port classes and the impact of 'raw: true'. This goes beyond the annotation safety profile 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?

Two sentences, both informative: the first gives the core purpose and output shape, the second clarifies the curated vs raw behavior. No wasted words, and the front-loaded main clause makes it easy to scan.

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?

This list tool has no output schema, so the description carries the burden of explaining return values. It does so partially (per-computer, one record, status ID per device class, example classes), which suffices for basic use but doesn't enumerate all possible fields or response paging details. Given the simplicity of the tool, this is adequate.

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

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

With 100% schema coverage, the schema already documents each parameter. The description adds specific meaning to the 'raw' parameter by explaining the curated default versus raw mode, which is valuable beyond the schema's generic 'full, unprojected records' description.

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

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

The description states a specific verb ('retrieves'), resource ('device control status'), and scope ('for all Windows computers'), and further details the output shape (one record per computer with a status ID for each device class). This clearly distinguishes it from sibling tools like dcm_mac_computer_device_status_list, which targets Mac computers.

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: this is for Windows computers, and the 'raw: true' option is explicitly noted for retrieving every device class. However, it does not explicitly name alternatives or state when not to use this tool, though the sibling list implies the Mac counterpart for Mac devices.

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 context by specifying the network-wide scope and the types of events returned. However, it does not disclose behavioral aspects like pagination behavior or that the list may span multiple pages despite the 'all events' wording, leaving some transparency gaps.

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

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

The description is a single, front-loaded sentence that states the main purpose first, then lists the content and filters. Every word contributes; there is no fluff 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?

Given 11 parameters, no output schema, and no nested objects, the description covers the key return fields and filter options, making it clear what the tool does at a high level. It doesn't explicitly mention pagination defaults or response shape, but the schema covers the parameters and the annotations cover safety, so it is nearly complete. The only gap is the absence of an explicit note about paginated results, which is minor given the presence of page/pageLimit in the schema.

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

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

The schema covers 100% of the 11 parameters with descriptions, so the baseline is 3. The description summarizes the filter categories (time period, computer, group, device type, block status, OS platform, domain) without adding details beyond the schema. It adds no new 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 starts with a specific verb ('Retrieves') and resource ('device activity events') within a clear domain ('Device Control Management'), then enumerates the fields returned and the filter options. It distinguishes itself from sibling tools like dcm_block_device_audit_list by covering all events, not just blocked ones.

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 when to use it: when you need to retrieve device activity events with optional filters. However, it does not explicitly mention alternatives or exclusions (e.g., 'for blocked events only, use dcm_block_device_audit_list'). The context is clear but no direct comparison to sibling tools is provided.

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

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

Annotations already disclose readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds value by detailing the content of the response (policy, target computer/user, exemption window, status) and the filtering capabilities, which goes beyond the basic safety profile. 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?

Two sentences, front-loaded with the core purpose and return fields. Every word earns its place; no redundant or vague phrasing. Excellent 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 list tool with 8 optional parameters, full schema descriptions, and read-only annotations, the description is complete: it states what is retrieved, the key result fields, and the available filters. Even without an output schema, the return field list gives a clear expectation of the response shape.

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

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

Schema description coverage is 100%, so all 8 parameters are already fully documented with descriptions and enums. The description's mention of filters (time period, OS platform, device type, exemption status, domain) restates the schema's parameter names without adding new semantics. 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?

The description uses a specific verb ('Retrieves') and clearly identifies the resource ('devices granted temporary exemptions from device control policies'). It also lists the key fields returned (policy, target computer/user, exemption window, status), which distinguishes it from sibling tools like dcm_device_type_exemption_list that focus on device types rather than individual devices.

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

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

The description specifies the available filters (time period, OS platform, device type, exemption status, domain), implicitly telling the agent when to use this tool: when listing temporarily exempted devices with those filtering needs. It does not explicitly name alternatives or exclusions, but the context is clear enough given the sibling tool names.

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 behavioral context by specifying the output fields (connection counts, last occurrence, block status) and supported filters, which goes beyond what annotations alone convey. It does not mention pagination or response structure, but the schema covers page/pageLimit.

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 verb and resource, and every phrase adds value: scope, returned fields, and available filters. There is no redundancy or fluff.

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 summary list tool with no output schema, the description adequately covers the tool's purpose, key returned data, and filter options. It does not explicitly describe the response envelope (e.g., pagination metadata), but the schema and annotations fill in most gaps, making it reasonably complete for the tool's complexity.

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

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

Schema coverage is 100%, and each parameter already has a detailed description, including enums with values. The description only paraphrases the schema's filter parameters ('OS platform, device type, and block status') without adding new meaning or usage details, so the baseline 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 clearly states 'Retrieves the list of unique devices detected in the network' with a specific verb and resource. It distinguishes from sibling DCM tools by emphasizing 'unique devices' and including connection counts, last occurrence, and block status, which are summary-level fields not mentioned in other tool names.

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 for getting a summary of unique devices, but it does not explicitly contrast with alternatives like dcm_device_audit_list or dcm_computer_device_status_list. No when-not-to-use guidance or sibling references are provided, leaving the agent to infer appropriate usage from the tool name and 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safe-read nature. The description adds the fields returned (policy, target, window, status) but does not disclose other behavioral traits like pagination defaults, sorting, or permission requirements. 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?

The description is a single, well-structured sentence that front-loads the core purpose and then lists the key filters. It is concise, information-dense, and free of fluff.

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

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

Despite having no output schema, the description provides a complete overview of what is returned (policy, target, window, status) and enumerates all five filter dimensions. The pagination parameters are already covered in the schema, so the description is sufficient for a read-only list tool.

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

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

Schema description coverage is 100%, so the schema already explains all 8 parameters. The description only restates filter names (time period, OS platform, device type, exemption status, domain) without adding new semantics or usage context 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 uses a specific verb ('Retrieves') and identifies the resource precisely: device types granted temporary exemptions. The parenthetical clarification ('whole classes, e.g. all disk drives') distinguishes it from the sibling tool dcm_device_exemption_list, which likely handles individual device exemptions.

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

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

The description gives clear context for when this tool is appropriate by emphasizing device-type-level exemptions rather than individual devices. However, it does not explicitly name alternative tools or provide 'when-not-to-use' guidance, 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, covering the safety profile. The description accurately describes a read-only retrieval operation without contradiction. It does not add extra behavioral context like pagination quirks or authorization requirements, but for a simple list tool this is adequate.

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 exactly two sentences: the first states the core purpose and returned fields, the second lists supported filters. It is front-loaded, uses no redundant words, and every phrase adds value without being verbose.

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

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

With no output schema, the description explicitly lists the returned fields (source file, shadow path, device, user, computer, status), which is essential. It also covers all filter dimensions supported by the parameters. It does not detail pagination or default behaviors, but those are documented in the schema, so the description is sufficiently complete for the tool's simplicity.

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

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

Schema description coverage is 100%, so all parameters are already documented with detailed descriptions (e.g., period, status, pageLimit). The description's mention of 'filters for time period, computer, group, domain, shadow status, and last-N-days activity' maps directly to schema properties but adds no new meaning beyond grouping them. 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 the specific verb 'Retrieves' and clearly identifies the resource as 'file shadow (mirror copy) operations' performed for files transferred to removable devices. It enumerates the returned fields and filters, making its purpose unambiguous and distinct from sibling tools like dcm_file_trace_list.

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 establishes the context for use: when you need to list shadow operations for removable-device transfers. It mentions available filters, giving practical guidance on narrowing queries. It does not explicitly contrast with alternatives, but its scope is evident; no exclusions are necessary given the 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; the description adds useful context about the content of returned records (file name/size, event type, process, device, user, computer) and the scope of data (across the network). It does not mention potential edge cases like empty results, but the annotation coverage lowers the burden.

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

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

The description is two sentences and about 40 words, front-loaded with the primary action and resource. Every clause adds information: the first sentence defines the data scope, and the second lists the filter options. No redundant 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?

Without an output schema, the description compensates by listing the returned fields (file name/size, event type, process, device, user, computer) and all the supported filter dimensions (event type, file extension/group, block status, device instance path, time period, computer, group, domain). This gives an agent a complete picture of what the tool returns and how to narrow it down.

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?

All 13 parameters have descriptions in the schema, achieving 100% coverage, so the baseline is 3. The description simply summarizes the filter categories (event type, extension, block status, etc.) but does not add details beyond the schema's per-parameter descriptions.

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 retrieves file activities with a specific verb ('Retrieves') and resource, and enumerates the event types (create, open, modify, delete, rename, move, copy, read). It also lists the data fields returned, which distinguishes it from sibling tools like dcm_device_audit_list and dcm_file_shadow_list.

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 when to use this tool (when you need file activity events across the network) and is clear on the scope. However, it does not explicitly name alternative tools or state when not to use it, so it misses the highest bar for explicit exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's 'Retrieves' aligns with that. The description adds useful behavioral context about the response structure (one record per computer, status ID per device class), which goes 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?

The description is a single, well-structured sentence that is front-loaded with the key action and resource. No wasted words, and it efficiently conveys the essential purpose and output shape.

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 read-only nature, strong annotations, and fully described parameters, the description is largely complete. It explains the return granularity and device classes (with 'etc.' implying more). It lacks explicit pagination behavior, but that is covered by the schema parameters, so the description is adequate for this simple list tool.

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

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

Schema coverage is 100% with descriptions for all three parameters (raw, page, pageLimit). The tool description does not add parameter-specific meaning, but the schema already provides adequate semantics, so the baseline 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 clearly states the tool retrieves per-computer device control status specifically for Mac computers, with one record per computer and status IDs per device class. It distinguishes from the sibling dcm_computer_device_status_list by explicitly limiting to Mac computers.

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 context is clear: use this tool when you need per-computer device control status for Mac computers. It does not explicitly name alternatives or exclusion criteria, but the 'for all Mac computers' phrasing implies its scope and differentiates it from similar 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. The description adds valuable context by explaining the meaning of moduleStatus values (0/1/2) and the distinction between total managed devices and DEX-managed devices, which goes 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 two sentences, front-loaded with purpose, and each sentence adds value. It avoids redundancy and is appropriately sized for a simple read-only 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?

Despite lacking an output schema, the description covers the essential aspects: what the tool returns (status and device counts), how to interpret moduleStatus, and when to use it. This makes the tool self-contained and complete for its purpose.

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 baseline is 4. The description correctly focuses on output semantics rather than parameters, explaining the fields and their interpretation.

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 retrieves the DEX addon module status and device counts, with a specific verb and resource. It distinguishes itself from sibling score tools by positioning itself as a preliminary check.

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 states when to use the tool: 'as a first check that DEX is licensed and active before calling the score tools.' This provides clear usage context and identifies alternatives (score tools) as subsequent steps.

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 known. The description adds value by enumerating the returned fields, including the score health enum values (0-3), which gives the agent expectations about output structure. No contradictions 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, well-structured sentence that front-loads the action and resource, then lists the returned data without unnecessary words. It is concise 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 simple read-only tool with two well-documented parameters and no output schema, the description covers the key aspects: what it retrieves, the specific fields, and the score health semantics. It does not explain failure scenarios, but the annotations and schema provide sufficient context for invocation.

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

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

The input schema contains detailed descriptions for both parameters (scoreProfileId, agentResourceId), including how to obtain them. With 100% schema coverage, the description need not repeat this. The tool description adds minimal extra parameter context beyond the schema, so a 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 begins with a specific verb ('Retrieves') and states the exact resource: 'DEX experience overview for one device under a score profile'. It distinguishes from sibling tools by emphasizing 'one device', which contrasts with metrics or latest scores tools. The listed fields further clarify the 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 description clearly implies the tool is for a single device's experience overview, but it does not explicitly name alternatives or say when not to use it. Sibling tools like dex_device_experience_metrics exist, but no comparison is made. Usage context is present but not fully 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. The description adds meaningful behavioral context: it explains the health scale (0 poor, 1 average, 2 good, 3 unknown) and that it can optionally restrict to metrics with issues, which goes beyond what annotations convey about the operation's nature.

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 that front-load the main verb and object, then detail the return payload and optional filter. No filler words 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?

With no output schema, the description clearly enumerates the returned fields (score, health with numeric mapping, display name, summary line) and the optional restriction. Given the tool's moderate complexity and annotations, this is sufficient 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?

Schema description coverage is 100%, and the schema already provides rich parameter descriptions (source for scoreProfileId from dex_meta, agentResourceId from som_computers_list). The description only lightly touches on filterType via 'Optionally restrict to only the metrics that currently have issues,' but does not add substantial meaning beyond the schema.

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

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

The description opens with 'Retrieves the indicator-wise DEX metric breakdown for one device under a score profile', a specific verb+object+scope. It lists the exact contained data (individual metrics with score, health, display name, summary line), making its purpose unambiguous and distinct from summary-level DEX 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?

It states the tool targets one device under a score profile and supports an optional 'metricsWithIssues' filter, giving clear context. However, it does not explicitly name alternative tools (e.g. dex_device_experience) or state when not to use it, though the scope is implicit.

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 semantic context by clarifying that the timestamp represents when the score summary was generated, which is not obvious from the name or title alone. 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 two sentences with no fluff. The first sentence states the action and resource, the second explains its practical purpose. Every word 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?

This is a simple metadata tool with no parameters, no output schema, and annotations that cover safety. The description fully explains what it returns and why it is useful, making it complete for its complexity.

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

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

The tool has zero parameters, and the schema fully reflects this with an empty properties object. With 0 params, the baseline is 4; the description correctly avoids adding any parameter-specific 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 uses a specific verb 'Retrieves' and a precise resource: 'the most recent time the DEX experience score summary was generated.' This clearly distinguishes it from sibling tools like dex_next_score_update_time (future time) and dex_latest_experience_scores (the scores 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?

The description explicitly states its use case: 'Useful for judging how fresh the scores returned by the other dex_* tools are.' This provides clear contextual guidance and implies these other tools are alternatives. It does not name specific alternatives, but the family reference is sufficient for the agent.

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 doesn't need to restate safety. It adds useful behavioral details: the health scale (0 poor, 1 average, 2 good, 3 unknown), inclusion of baseline and daily change, and per-category breakdowns. This goes 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?

The description is two sentences with a front-loaded purpose and no filler. The first sentence compactly lists return components, and the second adds optional scoping. Every sentence earns its place, and the structure is highly 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?

Given there is no output schema, the description adequately covers return values (overall, health, baseline, change, per-category) and scoping options. It doesn't mention pagination or error handling, but for a single-latest-score tool this is acceptable. It could be a 5 if it explicitly distinguished from sibling DEX tools to aid 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?

Schema coverage is 100%, so the schema already documents each parameter. The description adds semantic value by grouping the optional parameters as mutually exclusive scope choices ('a single device, a remote office, or a custom group'), which clarifies their relationship. It also reinforces that scoreProfileId is the required anchor.

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 ('Retrieves') and clearly identifies the resource ('latest DEX experience score for a score profile'), along with a detailed list of contents (overall score, health, baseline, change, per-category). While it doesn't explicitly distinguish from sibling tools like dex_device_experience, the 'latest' qualifier and field listing give a clear purpose.

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 (for retrieving the most recent score) and mentions optional scoping, but it doesn't explicitly state when to use this tool versus alternatives or provide exclusions. With sibling tools like dex_device_experience_metrics present, explicit differentiation would be helpful, but the implied usage is clear enough.

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 known. The description adds value by listing the specific returned fields (ruleset ID, statuses, initial score prepared flag, lastVisitedProfileId) and explaining the cross-tool usability of that ID, which goes beyond the annotation-only information.

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 dense sentence that front-loads the purpose and then lists all key output components. Each listed item adds meaning, and there is no filler, though the long enumeration makes it slightly less scannable than ideal.

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 tool with no parameters and no output schema, the description is fully self-contained: it enumerates every return value and even explains how one return value (lastVisitedProfileId) can be used in sibling tools. Nothing more is needed to invoke or interpret this tool.

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

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

There are no parameters, so the schema is trivially fully covered. Per the baseline rule for zero-parameter tools, the description doesn't need to convey parameter meaning, and it correctly provides no 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 uses a specific verb ('Retrieves') tied to a clear resource ('DEX module configuration and feature flags') and enumerates the exact items returned. It distinguishes itself from sibling DEX tools by focusing on configuration/feature flags and by explaining how lastVisitedProfileId is usable in the other DEX score 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 clearly implies when this tool is relevant — when you need configuration flags or a score profile ID to pass to dex_device_experience, dex_device_experience_metrics, or dex_latest_experience_scores. It provides strong contextual guidance without explicitly naming alternatives or exclusions, which fits the 'clear context, no exclusions' level.

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 known. The description adds useful context about what the time represents (when DEX scores refresh), but does not go further to disclose potential edge cases (e.g., what happens if no schedule exists). This is adequate but not rich 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 a single, well-structured sentence that front-loads the purpose and provides an explanatory clause. Every word earns its place, with no redundancy or unnecessary detail.

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 simplicity (zero parameters, no output schema, and annotations covering safety), the description is complete. It tells the user exactly what information is retrieved and why it matters, leaving no significant ambiguity.

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 baseline is 4 per the rubric. The description does not need to add parameter semantics, and the schema is empty. No issues.

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 ('Retrieves') and identifies the resource ('scheduled time of the next DEX experience score summary generation'), and clarifies its relationship to other dex_* tools by noting when scores will be refreshed. This clearly distinguishes the tool from siblings like dex_last_score_update_time.

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 for when to use the tool: when you need to know when DEX scores will next be refreshed. It implies usage but does not explicitly name alternative tools or state when not to use it, 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, and the description adds details about returned fields and supported filters. It does not contradict annotations and provides useful scope, though it omits details like response format 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?

Two sentences, front-loaded with the main purpose and key fields, then mentions filters. 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?

Despite no output schema, the description lists the data fields returned (user, file path, action, sensitivity) and mentions filtering and pagination, which is complete for a read-only list tool. The schema covers parameter details, so nothing critical is missing.

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

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

Schema coverage is 100%, so the description does not need to re-explain parameters. It briefly mentions 'filtering by action and pagination' but adds no new meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('Retrieves') and names the resource ('DLP activities performed on endpoints'), listing the key fields. It clearly distinguishes from sibling tools like dlp_network_device_report by focusing on endpoint activities.

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 that this tool is for endpoint DLP activities and mentions filtering and pagination. It does not explicitly compare with alternatives, but the word 'endpoints' and sibling naming imply when to use it.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, and the description confirms a read-only retrieval. It adds context about the source (endpoint users' override justifications) and the included fields, though it does not disclose pagination limits or matching behavior. The combination of annotations and description provides reasonable transparency without contradiction.

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

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

The description is two sentences, front-loads the primary action, and avoids redundancy with the schema. It is efficiently worded 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 read-only report tool with no output schema, the description adequately covers the purpose, key returned fields, filtering, and pagination. It doesn't clarify whether the justification message filter is exact/substring or the default ordering, leaving minor gaps, but the overall definition is sufficiently 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?

All four parameters have schema descriptions, covering the pagination and filtering options at 100% coverage. The description reinforces that filtering by justification message and pagination are supported, but it does not add additional semantic detail beyond the schema, warranting the baseline score.

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 identifies the tool as retrieving business justification messages for DLP overrides, listing the specific data fields (boundary type/value, event type, override comment, event time). This specific verb+resource distinguishes it from the many sibling DLP network/endpoint reports, which focus on different aspects.

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

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

The description implies the tool is for accessing DLP override justification data, but it does not explicitly state when to choose this over other DLP reports, nor does it mention any exclusions or alternatives. Context is limited to the tool's own capability rather than comparative 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 the operation as read-only and non-destructive. The description adds that the result is an aggregation (counts per boundary value) rather than raw events, and that it supports pagination and boundary-type filtering, providing context beyond simple read-only status.

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 convey the tool's purpose, output structure, and capabilities. The first sentence front-loads the verb and resource; the second succinctly notes filtering and pagination. No filler or repetition.

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

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

There is no output schema, so the description carries the burden of explaining return values; it does so by stating each row is a boundary value with the number of endpoints reporting false positives. Combined with annotations for safety and schema-covered parameters, the tool is fully specified for an agent to invoke 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?

All parameters are fully described in the input schema (100% coverage), so the description's mention of 'filtering by boundary type' adds no new detail beyond schema's enum explanations. It does not elaborate on pagination parameters, but schema already covers page/pageLimit defaults and caps.

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 the verb 'Retrieves' and specifies the exact resource: false positives reported by endpoints in the enterprise perimeter (containment boundaries). It clarifies the output structure (boundary value with endpoint count), which distinguishes it from sibling DLP reports that focus on specific boundary types or confirmed events.

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 establishes when to use the tool: to get an aggregate view of false positives by boundary value across the enterprise perimeter. It notes filtering and pagination, but does not explicitly compare against sibling tools like dlp_network_dcfp_report or the per-type reports, so alternatives are not ruled 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?

Detailed annotations already declare read-only/non-destructive behavior, so the bar for additional transparency is lower. The description adds useful behavioral nuance: results are grouped per triggered DLP data rule with endpoint counts, and it clarifies that filtering and pagination are available. No contradictions 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 two sentences, front-loaded with the core retrieval action and object, and every clause adds value: the aggregate nature, the filter, and pagination. No redundancy or fluff.

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 report with four optional, well-documented parameters and no output schema, the description adequately conveys the response shape (list of rules with endpoint counts) and options. It could lightly note the default field set or the absence of per-endpoint details, but the given info is largely sufficient for tool selection and 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?

All four parameters are fully described in the schema (100% coverage). The description's mention of 'filtering by rule class and pagination' maps to ruleClass and page/pageLimit but adds no semantic depth beyond what the schema already provides. It does not introduce param dependencies or special values beyond schema examples.

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: 'Retrieves false positives reported by endpoints for data rule violations' and clarifies it aggregates counts per rule. This clearly distinguishes it from adjacent DLP network reports (device, email, printer, etc.), which focus on different objects.

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 provides clear context that this is an aggregated false-positive report for data rules and mentions filtering by rule class and pagination. However, it does not explicitly state when to use this over sibling reports or when not to use it, leaving use-case differentiation implicit.

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 useful behavioral context beyond that, including that it retrieves all devices and supports pagination. This is valuable for setting expectations about result size and retrieval pattern.

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, consisting of one clear sentence with a short second sentence about pagination. Every word adds value and there is no redundancy or fluff.

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 simplicity (3 optional params, no output schema, read-only annotations), the description is fairly complete. It explains the core output (hardware devices with group counts) and pagination support. It does not detail return formats, but that is not required given the lack of output schema and the straightforward nature of the tool.

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

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

Schema description coverage is 100%, so all three parameters (raw, page, pageLimit) are adequately described in the schema. The description adds no extra parameter details, but per the baseline for high schema coverage, a 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 clearly states that the tool retrieves all hardware devices known to DLP, specifically by device instance path, and includes custom group association count. This is a specific verb+resource combination that distinguishes it from sibling tools like dlp_network_email_report or dlp_network_printer_report.

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 listing DLP hardware devices with group counts, but does not explicitly state when to use this tool over alternatives or mention any exclusions. It provides no explicit alternative guidance, but the purpose is clear enough to infer basic usage.

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

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

With annotations already declaring readOnlyHint=true and destructiveHint=false, the description adds value by specifying that the result is a paginated list and includes custom group counts per domain. It does not introduce any behavioral contradictions, and the read-only nature is consistent.

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 one concise, front-loaded sentence that states the purpose and key output detail. Every word earns its place, with no 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 read-only list report with no output schema, this description adequately conveys what will be returned (domains and custom group counts) and that pagination is available. Combined with the full schema and annotations, the agent has enough context to select and invoke 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 input schema covers 100% of the 3 parameters (raw, page, pageLimit) with detailed descriptions, so the description doesn't need to repeat them. It only mentions pagination in general terms, which aligns with the page and pageLimit parameters, but adds no extra semantic 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 clearly identifies the action ('Retrieves'), the resource ('all email domains deployed in DLP policies'), and the unique output aspect ('number of custom groups each domain is associated with'). It is easily distinguishable from sibling DLP network reports targeting devices, printers, products, rules, etc.

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 that this tool is for listing email domains in DLP policies, making it obvious when to select it over sibling DLP network reports. It does not explicitly state exclusions or alternative tools, but the domain-specific scope is sufficient 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 description's job is to add extra behavioral context. It adds that pagination is supported and that the output includes custom group counts per printer, which is useful beyond the annotation metadata.

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 main function and output without any filler. It is concise and well-structured, earning the highest score.

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 report with all-optional parameters and no output schema, the description sufficiently covers the tool's scope and pagination behavior. It could potentially note the distinction from USB printer reports, but the title and purpose clarity already handle that differentiation.

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?

All three parameters (raw, page, pageLimit) have descriptions in the schema, providing 100% coverage. The description adds minimal additional parameter meaning—it only mentions pagination, which is already described in 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?

The description clearly states the tool retrieves all network printers deployed in DLP policies and specifies the key output (number of custom groups per printer). This specific verb-resource combination distinguishes it from sibling reports like dlp_network_usb_printer_report, which target USB printers instead.

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—use this when you need network printers in DLP policies with custom group associations. It does not explicitly mention alternatives or exclusions, but the context is unambiguous enough to guide selection among similar report 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, so the safety profile is covered. The description adds behavioral value by noting that pagination is supported and that the tool retrieves 'all' applications, implying potentially large datasets. It does not detail return format or edge cases, but with annotations present, this is moderate-to-good 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 description is two sentences with no redundancy. The first sentence states the primary purpose and data scope, the second adds the pagination detail. Both sentences earn their place, making it concise and well-structured.

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

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

For a simple read-only list report with three optional parameters and no output schema, the description is complete. It specifies the data returned (enterprise applications, custom group counts), the scope (across the network), and pagination support. Given the low complexity and clear annotations, no additional detail seems necessary.

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

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

Schema description coverage is 100%, so all three parameters (raw, page, pageLimit) are fully documented in the schema. The description adds no additional parameter-specific meaning beyond mentioning pagination, which aligns with the page/pageLimit parameters. This meets the baseline for full 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 clearly states the tool's function: 'Retrieves all enterprise applications deployed in DLP policies across the network, with the number of custom groups each application is associated with.' This uses a specific verb ('retrieves') and resource ('enterprise applications deployed in DLP policies'), and it distinguishes this from its siblings (e.g., dlp_network_device_report, dlp_network_email_report) by the unique focus on applications.

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 that this tool is for obtaining enterprise applications in DLP policies and their custom group counts. While it does not explicitly name alternative tools or exclusions, the scope is unambiguous, and the sibling list confirms this is one of several specialized DLP reports. This meets the 'clear context, no exclusions' level.

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 known. The description adds useful behavioral context: it returns 'all' rules, includes per-rule custom group counts, and supports filtering/pagination. This goes 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?

The description is a single, well-structured sentence that front-loads the primary function, then adds the custom group count detail and the two key capabilities (filter, pagination). Every word earns its place; 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?

For a read-only listing tool with no output schema, the description covers the essential aspects: what is returned, the distinguishing aggregate (custom group count), and the available controls (filter and pagination). It does not enumerate return fields or edge cases, but none are required given the simplicity and good 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?

Schema description coverage is 100%, so the schema already documents all four parameters well. The description's mention of 'filtering by rule class' and 'pagination' only restates what the schema provides, adding no extra meaning beyond the structured definitions.

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 ('Retrieves') and resource ('all DLP data rules deployed in the network'), and adds the distinguishing detail of showing the number of custom groups per rule. This clearly sets it apart from sibling tools such as dlp_network_device_report or dlp_network_email_report.

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 clarifies scope (deployed network rules) and mentions filtering by rule class and pagination, which implies when to use it. However, it does not explicitly name alternatives or state exclusions, so guidance on when to use this tool versus the many other DLP/report siblings remains implicit.

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 behavioral details: it returns results 'by device instance path', includes custom group counts, and supports pagination. These details help the agent understand the output shape and the need to page through results. It does not describe default page size or error conditions, but that is not expected given schema coverage.

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

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

The description is two sentences, front-loaded with the core purpose. Every word earns its place: the first sentence states the resource and output composition, the second notes pagination. There is no redundant or vague language.

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

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

Given the moderate complexity (3 optional params, no output schema), the description is sufficiently complete. It explains the return content ('USB printers... with the number of custom groups') and pagination support. The lack of an explicit 'use this for USB, not network printers' note is a slight gap, but the name and description make that clear enough.

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%: all three parameters (raw, page, pageLimit) have descriptions. The tool description adds 'Supports pagination', which reinforces the purpose of page/pageLimit but does not add syntax or format details beyond the schema. This aligns with the baseline 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 clearly states the tool's function: 'Retrieves all USB printers deployed in DLP policies (by device instance path), with the number of custom groups each USB printer is associated with.' The verb 'Retrieves' and resource 'USB printers deployed in DLP policies' are specific. The parenthetical 'by device instance path' adds granularity, and the mention of custom group counts distinguishes it from sibling DLP reports (e.g., dlp_network_printer_report).

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: when you need USB printers in DLP policies with custom group association counts. It supports pagination, which signals how to handle large result sets. However, it does not explicitly compare with alternatives like dlp_network_printer_report, relying on the name and title for differentiation. This is a minor gap.

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 readOnly/destructive safety, so the bar is lower. The description adds useful behavioral context beyond annotations: it returns all web domains, includes custom-group counts, and supports pagination. It does not contradict the read-only annotation.

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 main purpose and followed by the count detail and pagination note. No redundant or filler content.

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

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

For a simple read-only report with well-documented schema and good annotations, the description is sufficient: it states what is returned, the aggregation included, and pagination support. A full output schema is absent, but the core return information is covered.

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 all three parameters (raw, page, pageLimit) described in detail. The description only mentions pagination, which aligns with page/pageLimit but adds no new semantics beyond the schema, so the 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 ('Retrieves') and clearly identifies the resource ('all web domains deployed in DLP policies across the network') plus the key output ('number of custom groups each domain is associated with'). This distinguishes it from sibling DLP reports focused on devices, email, printers, etc.

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 conveys the use case: when you need a report of DLP web domains with custom-group association counts. It does not explicitly name alternatives or exclusions, but the context is clear enough to guide selection among the sibling DLP report 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, so safety is covered. The description adds valuable context by specifying exactly which summary sections are included, giving the agent a clear picture of the returned data. No contradictions found.

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, well-organized sentence that front-loads the action and resource, then enumerates contents concisely with commas and conjunctions. 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?

Given no parameters, no output schema, and a simple read-only summary tool, the description fully covers the tool's behavior and return content by listing all summary categories. There is nothing missing for an agent to use 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?

There are zero parameters, so schema coverage is 100% and the description naturally needs no parameter details. Per the baseline for 0-parameter tools, this is a 4.

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 'Retrieves' and the specific resource 'overall Inventory module summary', then enumerates the exact content categories (scan/audit counts, software counts, license compliance, OS computers, warranty). This distinguishes it from the many sibling inventory tools that focus on specific lists or details.

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 word 'overall' establishes the tool as a high-level summary view, implying use when a broad inventory overview is needed rather than detailed per-computer or per-software data. It does not explicitly name alternatives or exclude cases, but the context is clear.

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

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

Annotations declare readOnlyHint=true, and the description's 'Retrieves' aligns with that. Beyond annotations, it adds valuable context by listing exactly what data categories are returned, helping the agent set expectations for the response. No contradiction or hidden side effects.

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, well-structured sentence that front-loads the action and resource, then lists the included content. No filler or redundant phrasing; every element contributes to understanding what the tool returns.

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 tool with one parameter and no output schema, the description is fairly complete: it specifies the input source and the output categories. It does not explain return format, but the enumeration compensates. Minor gaps around 'asset counts' detail, but overall sufficient 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 input schema already provides 100% coverage, including a description of resId as the resource_id from specific lists. The tool description itself adds no parameter-specific meaning, but the schema does the heavy lifting, so the baseline 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 states the verb 'Retrieves' and a specific resource: 'detailed inventory summary for one computer.' It enumerates the content categories (asset counts, OS details, disk usage, hardware summary, network adapters), which distinguishes it from sibling tools like inventory_all_summary that would cover all computers.

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 a per-computer summary, and the parameter description tells where to get resId from (som_computers_list or inventory_scan_computers_list). However, it does not explicitly state exclusions or name alternatives, so an agent might not know when to prefer this over similar inventory 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, so the safety profile is covered. The description adds the output fields (model, service tag, RAM, warranty) but does not disclose pagination behavior or the effect of the 'raw' flag beyond what the schema already states. It provides some added context but not richly.

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, well-structured sentence that front-loads the primary action and includes only essential details: the resource, the key identifier, its source, and the expected output fields. No filler or redundant wording.

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

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

With no output schema, the description compensates by explicitly naming the fields returned (model, service tag, RAM, warranty, computer details). Combined with fully described parameters and read-only annotations, this gives an agent enough context to invoke the tool correctly, though pagination defaults are only hinted in the schema.

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

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

Schema description coverage is 100%, so the schema fully documents all parameters. The description repeats the hwId source ('from inventory_hardware_list') but adds no new meaning beyond the schema, so it does not push above the baseline of 3.

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 ('Retrieves') and clearly identifies the resource (computers) filtered by a specific hardware component. It explicitly references the source (inventory_hardware_list) and lists returned fields, making it easy to distinguish from sibling tools like inventory_computers_by_software.

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 when to use the tool—when you have a hardware_id from inventory_hardware_list—but it does not explicitly mention alternatives or state when not to use it. This is adequate but lacks the explicit comparison or exclusion that would make it a 4 or 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 known. The description adds that the result includes license name and computer details, which is useful, but does not disclose additional behaviors like pagination or filtering beyond what the schema already provides. 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?

The description is a single, well-structured sentence that front-loads the action and resource. It includes the key input and output context without any redundant or filler 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?

Given the tool's moderate complexity (6 params, 1 required), the schema fully documents all parameters, and annotations cover safety. The description outlines the purpose and return content (license name and computer details). It is sufficiently complete for the agent to understand the tool's role, though it could mention pagination/filtering, but those are already in schema.

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

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

Schema description coverage is 100%, so all six parameters are documented in the schema. The description echoes licId's origin but adds no new semantics beyond the schema. Baseline score of 3 is appropriate when 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?

The description clearly states the action ('Retrieves the computers associated with a specific software license'), specifies the resource (computers), and identifies the key parameter (license_id from inventory_licenses_list). It also contrasts with sibling tools by focusing on license ID lookup, which distinguishes it from inventory_computers_by_software or inventory_computers_by_licensed_software.

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: it is used when you have a license_id from inventory_licenses_list and want the associated computers. It does not explicitly list alternatives or when-not-to-use cases, but the reference to the prerequisite source is sufficient for this straightforward retrieval tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that each computer's corresponding license is included in the result, which is useful behavioral context beyond basic read-only. It does not disclose pagination or filtering specifics, but those are in the schema.

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

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

The description is a single, concise sentence that conveys the core functionality and a key detail (license mapping). No unnecessary words or repetition.

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

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

The tool has six parameters and no output schema, but the description plus annotations and schema adequately cover the operation. It clearly states the primary purpose and the license mapping detail, while pagination and filter behaviors are already documented in the schema. Sibling tools provide additional context for differentiation.

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

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

Schema description coverage is 100%, so all six parameters already have descriptions. The description references licSwId's source (inventory_license_software_list), but the schema already provides this, so no additional meaning is added. The mention of license mapping hints at licenseFilter but not explicitly.

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 retrieves computers for a specific licensed software, using a specific verb ('Retrieves') and resource. It also mentions the inclusion of license mapping, which distinguishes it from sibling tools like inventory_computers_by_software and inventory_computers_by_license.

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 indicates the required parameter comes from inventory_license_software_list, providing clear context on the input source. However, it does not explicitly mention when to avoid this tool or name alternative sibling tools, so it lacks explicit exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by stating the result includes install location and exception-request counts, which is useful for understanding what the tool returns. It does not disclose additional behaviors like pagination defaults, but that is not required given the schema and 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 sentence, front-loaded with the main action, and includes only relevant details (source list and returned fields). No redundant wording.

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 tool with a well-covered schema and no output schema, the description provides enough context to select and invoke the tool: it names the source list for the key parameter and summarizes the return data. It does not enumerate all output fields, but given the tool complexity and sibling differentiation, this is adequate.

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

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

The schema has 100% coverage with descriptions for all 9 parameters, so the baseline is 3. The description adds an important cross-reference that prohibitedSwId comes from inventory_prohibited_software_list, which helps the agent populate the required parameter correctly. This cross-reference goes beyond what the schema provides, warranting a 4.

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 'retrieves' with resource 'computers' and defines the scope as 'a specific prohibited software' identified by software_id from a named source list. It also lists the returned data (install location, exception-request counts), differentiating it from sibling tools like inventory_computers_by_software.

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 indicates the tool is for prohibited-software detections and references inventory_prohibited_software_list as the source for software_id, giving clear context on when to use it. It does not explicitly name alternatives or exclusions, but the naming and the specific return fields strongly imply its purpose relative to sibling inventory_computers_by_* 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, so the safety profile is covered. The description adds context about the output (install date, version, computer details) and the link to inventory_software_list, but doesn't disclose pagination behavior, filtering defaults, or other non-obvious runtime characteristics. 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?

The description is a single sentence that is front-loaded with the action, contains no filler, and conveys purpose, key requirements, and output highlights in under 25 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 read-only inventory query with 9 parameters, the description gives the core purpose and key output fields, and the schema fills in filter parameter details. There is no output schema, but the description's mention of 'install date, version, and computer details' gives a reasonable expectation of the result set. It could be more explicit about pagination and the full list of computer details, but this is sufficient for an agent to invoke 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 input schema provides descriptions for all 9 parameters (100% coverage), so the baseline is 3. The description also reinforces the meaning of swId by referencing its source (inventory_software_list), but adds no deeper 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 uses the specific verb 'Retrieves' and clearly identifies the resource: computers with a specific software installed. It also references the source of the required parameter (software_id from inventory_software_list) and specifies output fields, distinguishing it from sibling inventory tools focused on hardware, licenses, or metering.

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 computers running a particular software, and it points to a prerequisite source for the ID. However, it does not provide explicit when-to-use vs alternatives or exclusions; given the many sibling tools like inventory_computers_by_licensed_software and inventory_computers_by_prohibited_software, it fails to guide selection among overlapping 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, so the description is consistent with those. It adds useful behavioral context by specifying the exact per-computer usage data returned (total run time, run count, last used) and references the source of swMeRuleId, providing value 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 a single, efficient sentence that front-loads the primary purpose and includes the key output fields without unnecessary 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?

The description provides enough context for a read-only listing tool: it identifies the required input, how to get it, and what output to expect. While pagination and filters are not mentioned in the description, they are well-documented in the schema, and the output fields are highlighted. This is adequate but not exhaustive.

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?

All 7 parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description repeats the swMeRuleId source from the schema but does not add additional semantic meaning to the parameters beyond what the schema already provides.

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

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

The description clearly states the tool retrieves computers for a specific software metering rule and lists the per-computer usage metrics, distinguishing it from other inventory tools by referencing the metering rule context.

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 by specifying that the tool is for a specific software metering rule and references how to obtain the rule ID from another tool. However, it does not explicitly name alternative tools or state when not to use it, so it earns a 4 rather than 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 safe read-only nature is handled. The description adds useful context by naming the exact categories of values it returns. It does not contradict 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 sentences, no filler. The first sentence lists the contents; the second explains how to use the result. Every word 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 helper used to fetch filter values, the description is fully sufficient. It names the value types and explicitly links them to the filter inputs of related inventory tools, making the tool's role in the broader toolset clear.

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 baseline is 4. The description does not need to explain parameters and instead focuses on what the tool returns, which 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 ('Retrieves') and clearly identifies the resource: valid values for inventory filters, listing concrete examples (OS names, software categories, manufacturers, hardware types). This distinguishes it from the many inventory report tools in the sibling list, making its purpose immediately clear.

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 explicitly states the intended usage: 'Use these values with the filter inputs of other inventory tools.' This gives clear context on when to call the tool, although it does not discuss when not to use it or mention alternatives (which are not really applicable here).

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 that it returns all detected hardware and includes counts, but does not disclose pagination defaults or response shape beyond that. With annotations covering safety, the description adds some context but not a lot.

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 concise sentences that front-load the action and key output fields. No fluff, every word 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?

The absence of an output schema is mitigated by the description naming key fields (manufacturer, type, counts). The schema covers pagination and filtering. The pointer to inventory_filter_params fills a gap in filter value information, making the description sufficiently complete for a moderately complex list tool.

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

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

Schema coverage is 100%, so the schema fully documents all parameters. The description adds a pointer to inventory_filter_params for valid filter values, which is helpful but does not add significant semantic meaning beyond the schema's own descriptions.

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 retrieves hardware components with manufacturer, hardware type, and counts, using a specific verb and resource. It distinguishes from siblings like inventory_all_summary (which likely summarizes) and inventory_computer_details_summary by focusing on hardware components across the network.

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 for listing hardware inventory but provides no explicit guidance on when to use this tool versus alternatives. It only points to inventory_filter_params for valid filter values, which is a helper reference, not a usage guideline for tool selection.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description is not required to restate safety. It adds context about the returned fields (version, manufacturer, license status, prohibited usage), which is useful. However, it does not disclose behavioral details like pagination behavior or filtering semantics beyond what the schema already provides.

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 directly states the tool's purpose and output scope. There is no verbose or redundant content; every phrase 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?

For a read-only list tool with rich schema coverage and clear annotations, the description sufficiently conveys the core purpose and return fields. It does not explain pagination or filters, but the schema covers those details. The absence of an output schema is partially compensated by enumerating the returned attributes. Slightly more context about when to use this over sibling tools would improve completeness, but the essential information is present.

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

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

Schema description coverage is 100%, so the input schema fully documents all 8 parameters. The description adds context about the output fields but does not add meaning beyond what the schema property descriptions already provide for parameters. Baseline 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 ('Retrieves') and clearly identifies the resource ('software installed on a specific computer') with a detailed list of returned attributes. It distinguishes itself from siblings like inventory_software_list and inventory_license_software_list by emphasizing the per-computer scope and inclusion of license/compliance/prohibited status.

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 states what the tool does but provides no guidance on when to use it versus alternatives such as inventory_software_list or inventory_prohibited_software_list. There is no mention of scenarios where this tool is preferred, nor any exclusions 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 known. The description adds behavioral context by listing the curated default fields (license name, edition, copies, mapped computer count, purchase/expiry dates, purchase details) and noting that raw:true reveals license key and file-path fields. This goes 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 two concise sentences, front-loaded with the core purpose. The second sentence efficiently introduces the raw option without extra fluff. Every clause 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?

For a read-only list tool with 4 parameters (1 required) and no output schema, the description covers the purpose, key output fields, and the raw option. Combined with schema and annotations, this is sufficient. Pagination or error behavior are not described but are peripheral for this tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning by clarifying what the 'curated default field set' includes and what raw=true provides, which is not fully captured in the schema's generic 'full, unprojected record' for the raw 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 uses a specific verb 'Retrieves' with a concrete resource 'licenses' and clear scope 'for a specific software (by software_id)'. This distinguishes it from sibling tools like inventory_software_list or inventory_license_software_list, which focus on software rather than licenses.

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 by stating 'by software_id', and the schema for swId explicitly references 'from inventory_license_software_list' as the source. This gives clear context for when to use the tool, but 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 read-only behavior, and the description adds meaningful context by specifying returned metrics (copies counts, compliance status, network installation counts) and the licensed-software scope. It does not contradict annotations, though it omits details like pagination behavior beyond schema.

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

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

The description is a single sentence that front-loads the primary purpose and packs essential output fields into a concise structure. No filler or redundant wording is present.

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

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

For a read-only list tool with no output schema, the description provides a solid overview of the primary data returned: copies, compliance states, and network counts. It lacks explicit mention of default ordering or how it relates to sibling inventory queries, but the core context is sufficiently covered.

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 all four parameters are already documented with types, defaults, and enum labels. The description adds no new parameter-specific meanings; the compliance status mentions mirror the schema's enum descriptions.

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 ('Retrieves') and clearly defines the resource: software that has license records. It distinguishes this from sibling tools like inventory_licenses_list and inventory_software_list by emphasizing license-linked software and compliance-related computed fields.

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 when license compliance information is needed, but it does not explicitly state when to use this tool versus alternatives such as inventory_licenses_list or inventory_software_list. No exclusions or alternative guidance are provided.

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

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

Annotations already declare read-only and non-destructive behavior, so the description need not repeat that. It adds content details (installation counts, installer format, uninstall support) but does not disclose pagination behavior, ordering, or potential performance implications, which are not covered by 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 concisely states the purpose and key data fields. No redundant phrasing or filler 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 read-only list tool with strong annotations and full schema coverage, the description is fairly complete. It mentions the core data returned and implicitly supports filtering via the format and uninstall fields. Missing details like pagination limitations are already in the schema, and no output schema exists, so the description need not explain return 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 schema provides 100% coverage for all five parameters, including enums for installer format and uninstall support. The description mentions these fields but does not add meaning beyond the schema. The pagination parameters are not described in the description, but the schema already handles them, so baseline 3 applies.

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

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

The description clearly states the tool retrieves prohibited software across the network with specific fields like installation counts, installer format, and uninstall support. It identifies the resource precisely and implies a focus on the software list itself, distinguishing from sibling 'inventory_computers_by_prohibited_software' which targets computers, though the distinction is not explicit.

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

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