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

No annotations are provided, so the description carries full burden. It discloses case-insensitive matching and that it reports what it did NOT check, setting correct expectations about the strength of a negative result. This is meaningful behavioral context beyond 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?

Three sentences, each earning its place: what it searches, an example and use case, and a caveat about the meaning of 'no references found'. 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?

Covers search scope, use case, matching behavior, and a limitation. There is no output schema, and the description doesn't specify the exact return format, but it provides enough context for an agent to understand what the tool does and when to invoke it.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds a small amount of meaning by clarifying that query matches field names and criterion values, but it does not add detail about the concurrency parameter beyond its default and range.

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+resource: 'Search smart computer group criteria, advanced computer search criteria, and advanced search display fields for a term.' It also includes an example ('Home Directory') and clearly distinguishes the tool from sibling findObjectReferences by scoping to computer group criteria and display 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?

Provides a concrete use case ('to find out whether anything consumes that inventory field before disabling its collection') and explains when the result is weaker ('no references found' is weaker than a hit). It implies when to use the tool without explicitly naming alternatives, but the context is strong enough for an agent to decide.

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?

Discloses several behavioral traits beyond the schema: case-insensitive substring matching, return fields, and the fact that both group types come from a single gateway list. No annotations exist, so the description carries this burden; while it omits pagination details, those are covered 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 two sentences long and front-loaded with the core action and return fields. Every sentence contributes value, with 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 search tool with rich schema coverage, the description fully covers purpose, scope, matching behavior, and return values. Without an output schema, specifying the returned fields is necessary and handled. The limit behavior is already documented in the schema, so no gaps remain.

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 the case-insensitive detail, but most parameter semantics (query substring, limit default and max) are already in the schema, so no substantial additional meaning is provided.

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 a specific action ('Search device groups by name or description') and specifies the return fields. It distinguishes itself from sibling tools like getComputerGroup and findDevices by focusing on substring search across group metadata.

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

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

Provides clear context by noting it covers both computer and mobile groups, smart and static, which implies a broad search use case. However, it does not explicitly mention alternatives or when not to use, but the scope statement effectively guides selection.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It explicitly discloses the client-side filtering implementation, pagination behavior, case-insensitive substring matching, and platform coverage (macOS and iOS/iPadOS). This goes well beyond the schema and gives agents critical insight into how the tool operates.

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 with no filler. The first sentence states the core purpose and searchable fields, while the second adds essential implementation context about pagination and platform coverage. Every clause contributes meaning, and the key information is front-loaded.

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

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

For a simple search tool with two parameters, no output schema, and no annotations, the description provides all necessary context: what it searches, how matching works (case-insensitive substring), what platforms it covers, and its implementation behavior (client-side filtering). No critical information appears missing for an agent 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 schema covers both parameters with descriptive text (100% coverage), so the baseline is 3. The description adds value by clarifying that 'serial' means serial number, 'id' means device id, 'user' means user id, and by stating the matching is case-insensitive—details not fully present in the schema. This enhances understanding 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 clearly states it searches the fleet by specific fields (serial number, device name, model, device id, or user id) with case-insensitive substring matching. This specific verb+resource combination distinguishes it from sibling find tools that target different resources, such as findOutdatedDevices or findDeviceGroups.

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 notes that it paginates and filters client-side due to no confirmed server-side filter, which implies performance considerations but does not explicitly state when to use this tool versus alternatives. No exclusions or alternative tool references are provided, so guidance is implied rather than 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?

With no annotations, the description carries the behavioral disclosure burden. It explicitly states 'Read-only' and explains the tool's logic, including why extension attributes are highlighted (they execute at every inventory collection). It does not mention rate limits or output format, but the core safety and operational traits are disclosed.

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

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

The description is efficient and well-structured. It opens with the main audit action, provides concrete examples of problematic commands, highlights a key distinction (EAs), and ends with a memorable, useful use-case phrase. 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?

The tool has no output schema, so the description appropriately explains what the tool reports (which policies run the expensive commands and how often). It covers the core scope and the EA caveat. Minor gaps include not specifying the exact output format or behavior when no results are found, but overall it's sufficient for this 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 schema already provides 100% coverage with descriptions for all three parameters, so the baseline is 3. The description adds no further parameter-specific meaning beyond naming the resource kinds, but it doesn't need to since the schema is sufficient.

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 with a specific verb ('Audit'), the target resources (Jamf scripts, extension attributes, policies), the specific behavior (identifying CPU/battery-heavy commands), and the output (report which policies run them and how often). It distinguishes itself from sibling find/list tools by focusing on an audit of expensive automations.

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 a clear use case ('Answers "what is cooking this laptop's battery"') and context for when to use the tool, but it does not explicitly mention alternatives or exclusions. It's clear this is a specialized audit tool rather than a general lookup, which is sufficient for usage 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?

With no annotations provided, the description carries the full burden and delivers richly: it discloses that cycles are reported as node paths, missing group references are surfaced, blast radius is transitive with depth, 'not member of' is treated distinctly, and unfetched groups are named to avoid implying independence. This goes far beyond a generic mapping description.

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

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

The description is long but every sentence adds unique value, covering purpose, outputs, edge cases, and failure behavior. It is front-loaded with the core purpose and then layers nuance. No fluff or repetition of schema details.

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 graph analysis tool with no output schema, the description covers return types (cycles, missing refs, blast radius, distinct criterion types), error cases (unfetched groups), and parameter semantics. It leaves no obvious gap for an agent to misuse or under-trust 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 coverage is 100%, so the schema already documents both parameters. The description adds semantic depth by explaining 'blast radius' (transitive changes with depth), which elaborates on the 'group' parameter's purpose. The 'concurrency' parameter is self-explanatory with its default, and the description doesn't repeat it but complements the schema.

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

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

The description opens with a specific verb and resource: 'Map which computer groups depend on which others, via Computer Group membership criteria.' It clearly distinguishes this from sibling tools like getComputerGroup or findDeviceGroups by focusing on dependency mapping rather than listing or retrieving individual groups.

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

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

The description implies usage context: it maps dependencies, reports cycles, missing references, and blast radius given a group. It doesn't explicitly name alternatives or exclusions, but its specialized purpose makes it evident when to use it. The 'given a group' clause signals an optional input pattern, and 'Omit for the whole graph' in the schema further clarifies 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 no annotations provided, the description carries the full burden. It discloses exact matching rules (case-insensitive, not substrings), distinguishes exclusions from inclusions, and critically explains the coverage limitation and the meaning of the `strength` field. This is exceptional behavioral 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 dense but every sentence adds value: purpose, reported locations, exclusion distinction, matching rules, coverage caveat, and strength field. It is front-loaded with the main action and contains 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?

Given the tool has no output schema and 4 parameters, the description covers the critical aspects: what it returns (locations), key limitations (partial coverage), and the strength field. It could be more explicit about the overall output structure, but it is adequate for a complex 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 reiterates the name matching behavior already present in the schema but adds no new parameter-specific semantics. It does mention `strength` as an output field, not a 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 states a specific verb 'Find' and resource types (package, computer group, script), and clearly frames the tool as a pre-deletion/changing check. This distinguishes it from sibling search tools like findCriteriaReferences or findGroupDependencies.

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 says this is 'the check to run before deleting or changing one' and warns that partial-clear results must not be read as permission to delete. It provides a clear when-to-use and a when-not-to-trust, but does not name alternative tools explicitly, 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?

With no annotations, the description carries full weight. It discloses ordering ('oldest first'), output detail ('freshest activity timestamp for each'), the separate grouping of missing/unparseable versions with rationale, and platform coverage. This gives the agent a clear behavioral model beyond 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?

Three sentences with no waste. Each sentence adds distinct value: the core action with ordering, the special handling of unknown versions, and the platform scope. Front-loaded and efficient.

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

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

The tool has only two parameters, no output schema, and no annotations. The description covers the essential behavior (listing, ordering, grouping, platforms) sufficiently for an agent to understand what the tool returns and when to use it. No critical gaps remain.

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 both parameters are already well-documented. The description adds context about the threshold behavior and unknown versions, but does not significantly enhance parameter meaning beyond what the schema provides. 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's function: 'List devices whose OS major version is below a threshold' with a specific verb and resource. It also distinguishes from siblings by mentioning 'Spans macOS and iOS/iPadOS/tvOS' and the separate handling of unknown versions, which sets it apart from generic device listing 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 provides clear context for when to use the tool (identifying outdated devices by OS version threshold) and implies a comparison with generic device finders. It does not explicitly name alternatives or provide exclusions, but the specificity of the use case is sufficient for an agent to select it appropriately.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains evaluation order, parentheses/join preservation, the member count, the ambiguous-name candidate fallback, and the subtle regex containment trap, all of which are non-obvious behaviors.

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 composed of four dense sentences, each providing unique information: core function, a critical caveat, input resolution behavior, and member inclusion policy. It is front-loaded with the main purpose, and every clause earns its place without redundancy.

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

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

Given the complexity of the tool (criteria evaluation) and the lack of an output schema, the description covers input interpretation, output composition, and edge cases (ambiguous names, regex semantics). It could explicitly mention the return format, but the essential information needed to use the tool effectively 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?

Although the schema descriptors already cover all three parameters, the description adds semantic meaning: 'Accepts a group id or a name substring' clarifies the group input, and 'Members are NOT included unless asked for' plus 'a count is always returned' enriches understanding of includeMembers and the output. This goes beyond the schema's basic 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 identifies the tool as 'Read a computer group's criteria' with specific details like 'in evaluation order' and 'plus a member count'. This distinguishes it from sibling tools like getDeviceGroupMembers, which presumably return member lists, and findDeviceGroups, which finds groups.

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 context on how to use the group parameter ('id or name substring') and clarifies the default behavior for members ('Members are NOT included unless asked for'). Though it doesn't explicitly name alternative tools or when-not-to-use, the scope is well defined, and it implies that members are rarely the question.

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?

Since no annotations are provided, the description fully discloses key behaviors: grouping of failures, device name/serial resolution, the PENDING exclusion limitation, the wildcard pitfall, and the existence of excludedFromThisAnswer in results. This is exceptionally transparent for a tool with no annotation support.

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 main description is four sentences, each with a distinct purpose: function, output enrichment, sibling relationship, and critical limitation. The parameter descriptions are detailed but relevant, and the overall structure is front-loaded with purpose. 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?

With no output schema, the description compensates well by mentioning status, validity, reasons, grouping, and excludedFromThisAnswer. It covers the tool's purpose and main edge cases. It could optionally specify whether results are paginated or the exact response shape, but for a tool with simple parameters, the coverage is strong.

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%, but the description adds significant value beyond the schema: it explains the filter's default value, allowed fields, the wildcard trap, and clarifies that declaration is exact and not a substring. These details help avoid misuse and go far beyond basic type 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 clearly states the tool reports every device for a given DDM declaration, including status, validity, and grouped failure reasons. It explicitly differentiates from the sibling tool by saying 'The inverse of getDeviceDeclarationState', making the purpose unambiguous.

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

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

The description provides explicit alternatives (the inverse statement), when-not-to-use guidance (PENDING declarations are excluded, so an all-healthy answer is not proof of full deployment), and required prerequisites (filter is required). This gives clear context for when to rely on the tool and when to be cautious.

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

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

With no annotations provided, the description fully carries the behavioral transparency burden. It discloses crucial behaviors: ambiguous substrings return candidates rather than guessing, and PENDING declarations are excluded from filtered reads, with a pointer to 'excludedFromThisAnswer' in the result. This goes well beyond basic expectations and gives the agent a clear picture of edge cases.

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

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

The description is a single paragraph, but each sentence is informative and earns its place. It front-loads the core purpose, then adds relational context and a critical caveat. It is not overly verbose, though it could be slightly more concise without losing meaning. Overall, it is well-structured and readable.

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

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

Given there is no output schema, the description should explain return values, and it does so reasonably by mentioning 'status and validity', 'reasons Jamf gives', 'candidates', and 'excludedFromThisAnswer'. It also covers important edge cases like PENDING exclusions. While it does not enumerate every return field, it provides enough context for an agent to understand what to expect and how to interpret the result.

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

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

The schema already provides 100% coverage of parameter descriptions, so the baseline is 3. The description adds value by explaining that an ambiguous device substring returns candidates rather than guessing, which is not in the schema. It also gives a note about PENDING declarations that relates to the filter's default behavior. This additional semantic context elevates the 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 states the tool's function: 'Report the declarative device management (DDM) state for one device: which declarations are applied, their status and validity, and — for anything that failed — the reasons Jamf gives.' This is a specific verb+resource combination. It also distinguishes itself from siblings by describing itself as 'The companion to listBlueprints', clarifying its unique role relative to a related tool.

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

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

The description explicitly positions the tool as 'The companion to listBlueprints', giving clear relational guidance on when to use it. It also explains the input behavior (substring may return candidates) and warns about PENDING declarations being excluded, helping the agent decide when this tool is appropriate. However, it lacks explicit 'when not to use' exclusions or comparisons to other related tools like getDeclarationScope.

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

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

With no annotations provided, the description carries the full burden and does so well. It discloses the resolved output fields, the ambiguous-name behavior (returns candidates instead of guessing), and the separate reporting of member IDs with no matching device. These are valuable behavioral traits beyond 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 three sentences long, with the main action stated first and important edge cases packed into the following sentences. Every sentence adds value, 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?

Given the tool has only 2 parameters and no output schema, the description provides sufficient context: it describes what is returned (resolved fields) and how missing members are handled. The ambiguous name behavior is also disclosed, making the tool's behavior predictable for an agent.

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 both parameters, so baseline is 3. The description adds meaning beyond the schema by explaining the ambiguous name behavior for the group parameter, which tells the agent what happens if the name is not unique. This enriches the semantic understanding without being redundant.

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: listing devices in a device group with resolved attributes (names, serials, platform, last-seen time). The verb 'List' is specific, and the resource 'devices in a device group' distinguishes it from related tools like findDeviceGroups or findDevices.

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 usage context: it accepts a group UUID or name substring and handles ambiguous names by returning candidate groups. However, it does not explicitly state when to prefer this over sibling tools like getComputerGroup or findDevices, nor provides exclusion criteria.

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

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

With no annotations, the description carries the burden and provides valuable behavioral details: it fetches devices, groups, and blueprints concurrently; notes the device total includes both macOS and iOS/iPadOS (not just Macs); and states that partial failures are reported individually. These go beyond the name and help set expectations, though it omits auth/rate-limit details.

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

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

The description is two sentences, front-loaded with the main summary, and every clause adds value: the caveat about device totals prevents misinterpretation, and the failure-mode note clarifies behavior. No fluff or redundancy.

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

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

For a read-only aggregation tool with no output schema, the description covers what data is returned, how it behaves (concurrent fetching), and important caveats (cross-platform total, partial failures). It does not describe return formatting or default values, but those are partially in the schema, and the complexity is well addressed for an overview 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 already has 100% coverage with detailed descriptions for both parameters (topGroups and staleThresholdDays). The description adds only indirect hints (e.g., 'stale check-ins' relates to staleThresholdDays) but does not need to compensate given the schema's thoroughness. 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's purpose as a 'one-call fleet summary' and enumerates specific data it provides (device counts by platform/OS, managed status, stale check-ins, device-group breakdown, blueprint states). It distinguishes itself from sibling tools like findDevices or listBlueprints by positioning it as an aggregated overview rather than a raw listing.

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

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

The phrase 'one-call fleet summary' implies using this tool when you need a broad overview instead of making multiple find/list calls. It does not explicitly name alternative tools or state when not to use it, but the context is clear enough to guide 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?

With no annotations, the description carries the full behavioral burden. It explains that the tool rates options by cost, specifically flags home_directory_sizes as high cost, and details why (running du across all user home directories, leading to battery drain). This is rich behavioral context beyond just 'read settings'.

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

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

Three sentences, each earning its place: purpose, cost explanation, and pairing recommendation. The description is front-loaded with the core action and then adds valuable context without 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 zero-parameter read tool with no output schema, the description fully covers what the tool does, why it matters (cost analysis and battery impact), and how to use it alongside another tool. Nothing important is missing.

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

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

There are zero parameters, so the schema fully covers the input. The baseline is 4 for no-parameter tools, and the description doesn't need to add parameter semantics. It doesn't, but that's acceptable.

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 ('Read the tenant computer inventory collection settings') and the unique output ('rate each option by how much work it adds per collection'). It also distinguishes itself by naming a complementary sibling tool (findExpensiveAutomations), making the purpose unambiguous.

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

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

The description provides explicit usage guidance by recommending pairing with findExpensiveAutomations to see how often inventory is triggered. It also gives a concrete example of when this tool is useful (diagnosing a du process under JamfDaemon), helping the agent decide when to invoke 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It explicitly states the required auth scope (read:pro:blueprints) and clarifies a common confusion about the scope prefix vs. URL segment, adding useful behavioral context.

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

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

Two sentences, no wasted words. The main action is front-loaded, and the scope clarification is concise and relevant.

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 operation with no parameters and no output schema, the description covers the essential context: the resource, tenant, and required permission. It could optionally mention return format, but this is not critical for such a straightforward 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 tool has zero parameters, so no parameter-specific description is needed. The schema is empty and description provides no parameter details, but the baseline for zero params is 4, and this description does not attempt to compensate for undocumented params because none exist.

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 lists Blueprints for the configured tenant, using a specific verb and resource. It does not explicitly distinguish itself from sibling tools like findDevices or getFleetOverview, but the resource name is unique enough.

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 context about the tenant and required scope but offers no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites beyond the scope requirement.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It explicitly states the tool is GET-only and has no method or body parameter, discloses that 'flat' style has never returned 200, explains that rawPath requires the tenant segment or returns 400, and notes that Jamf Pro versions are per-resource. This goes far beyond basic safety annotation coverage, providing critical operational expectations.

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 dense but every sentence earns its place: purpose, scope, path construction, versioning, and design rationale. It is front-loaded with the core purpose and read-only guarantee, then progressively details layout options. The length is justified by the tool's generic nature, which requires extensive clarification to be used safely.

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 complexity (a generic passthrough with multiple path styles, no output schema, and no annotations), the description is exceptionally complete. It covers all key behavioral aspects, path construction, versioning, service segments, and provides strong guidance on when to avoid it. The rationale for why writes are excluded (unreviewable) adds crucial context for safe usage.

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?

Although schema coverage is 100%, the description adds substantial meaning beyond the schema. It clarifies the 'tenant' default, explains that 'classic' fills the tenant automatically and omits the version segment, details rawPath verbatim behavior, and notes service can be multi-segment (e.g., 'ddm/report'). This transforms the parameter descriptions from raw definitions into actionable usage rules.

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 makes authenticated GET requests against any Jamf Platform API Gateway endpoint, covering both Jamf Pro and Classic APIs. It explicitly distinguishes itself from the typed sibling tools by emphasizing that writes go through named typed tools, not this passthrough. The READ-ONLY BY DESIGN statement and mention of 300+/500+ endpoints make the tool's purpose and scope unmistakable.

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

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

Provides explicit guidance on when to use this tool (for any GET request against the gateway, including endpoints not covered by typed siblings) and when not to (writes must use named typed tools). It also offers detailed usage instructions for path styles (tenant vs. classic vs. flat), rawPath requirements, service segment composition, and version selection, making it clear how to choose alternatives like style 'classic' over rawPath. The reference to JPM-0007 suggests additional context.

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