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

No annotations are provided, so the description carries the full burden. It discloses that this returns metadata (available types) rather than actual connections, and mentions that credential fields are included. However, it does not mention any authentication requirements, rate limits, or return format details. For a read-only list operation, this is acceptable but not exhaustive, so a 3 is appropriate.

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

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

The description is two sentences with zero filler. The primary action and key detail (including required credential fields) are front-loaded, followed by the important differentiation from the sibling. 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 simple list operation with optional parameters fully documented in the schema, the description covers the core purpose and the key differentiator. It does not mention pagination or result ordering, but those are implicit in the schema. Given the low complexity and no output schema requirement, the description is largely complete, though a note about response format could push it to 5.

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

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

All three parameters (page, page_size, vendor_type) are fully described in the input schema (100% coverage). The tool description does not add any additional semantic context about how these parameters affect the results. Since the schema already covers them, the description adds no extra value here, so it meets 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?

Description states a specific action (List integration types) and a clear resource (integration types for Cork). It explicitly differentiates from the sibling cork_get_connected_integrations by noting the distinction between what CAN be connected vs what IS connected. This is unambiguous and distinguishable without needing the schema.

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

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

The description directly tells the agent when to use this tool ('Metadata about what CAN be connected, not what IS connected') and names the alternative tool (cork_get_connected_integrations) for the complementary use case. This is explicit routing guidance with no ambiguity.

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 burden; it clearly signals a read-only list operation, defines the meaning of can_install_software, and explains normalized OS/device-type details. It does not discuss pagination or response envelope, but the schema covers pagination and 'List' implies non-mutating.

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

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

Three compact sentences front-load the core action and scope, then pack output-field semantics, a cross-tool usage hint, and the prerequisite without redundancy. Every sentence earns its place.

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

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

For a simple paginated list with one required parameter, the description covers output fields, scope, and a prerequisite, while the schema covers paging. No output schema exists, but the enumerated fields give an agent a good mental model of the result; an explicit page-size/return-envelope note would make it fully complete.

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

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

All three parameters are already documented in the schema (100% coverage), so the baseline is 3. The description adds meaningful connectivity by sourcing client_uuid from cork_get_clients, but adds nothing about page/page_size 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 starts with a specific verb and resource ('List devices observed for a client across all connected integrations') and enumerates the returned fields. The 'across all connected integrations' scope distinguishes it from sibling cork_get_integration_devices without needing to open schemas.

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

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

It gives a clear context: client-level device inventory aggregated over integrations, and an explicit prerequisite ('Requires a client UUID from cork_get_clients') plus a downstream use for device UUIDs. It does not name alternatives or state when not to use it, but the context is clear enough for 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 behavioral burden. It signals a read-only list operation and adds useful context that domain UUIDs can filter cork_get_compliance_events. However, it does not disclose pagination behavior, ordering, or what fields the listed domains contain, leaving the agent to infer some runtime 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?

Two focused sentences with no filler. The primary action is front-loaded, followed by the most important precondition and a useful downstream pointer.

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 endpoint, the description covers the core purpose, the required input source, and the consumer of the output domain UUIDs. Pagination parameters are fully documented in the schema. The only minor gap is the lack of an explicit output shape, but this is mitigated by the implied domain+UUID result set.

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 mostly restates the client_uuid provenance already present in the schema and adds the downstream use of returned domain UUIDs. It does not add significant new 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 states a specific verb and resource: 'List email domains observed for a client.' It also clarifies the downstream purpose of the returned domain UUIDs, making the tool clearly distinct from siblings like cork_get_clients and cork_get_compliance_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?

It gives a clear prerequisite: 'Requires a client UUID from cork_get_clients.' This tells an agent where the required input must come from. It does not explicitly say when not to use this tool or name alternatives, but the context is otherwise 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?

There are no annotations, so the description carries the behavioral burden. It describes a read-only list operation and adds the useful 'observed for a client' scoping, but it does not discuss pagination behavior, authentication requirements, or potential staleness. For a simple list tool 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, information-dense sentence that front-loads the purpose and includes the prerequisite. There is no fluff or repetition of schema content beyond the necessary client UUID dependency.

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 helps by enumerating what the response includes: inbox type, associated domains, and integration source. It omits details like ordering and pagination defaults, but those are covered by the input schema and the tool's low 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%, so the schema documents all parameters. The description's client UUID mention mostly repeats the schema property description and adds little new meaning. Page and page_size are fully covered by the schema, so this is at the baseline.

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

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

The description states the exact verb ('List'), resource ('email inboxes'), and scope ('for a client'), and even lists the returned attributes (inbox type, associated domains, integration source). This clearly distinguishes it from sibling tools such as cork_get_client_domains and cork_get_client_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 gives a clear prerequisite: 'Requires a client UUID from cork_get_clients,' which tells an agent how to sequence the call. It does not explicitly mention alternatives or exclusions, but the use case is obvious from the context and sibling 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?

With no annotations provided, the description carries the full burden. It discloses the cap of 10 most recent scores, the newest-first ordering, and the inclusion of hidden/archived clients only when show_hidden is true (via parameter). It implies a read-only operation by saying 'List' but does not explicitly state that no mutations occur. This is adequate, though it could be more explicit about side-effect absence.

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

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

The description is compact and front-loaded: it states the core function and key outputs first, then gives the alternative and prerequisite context, and finally the distributor-specific usage. Every sentence 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 there is no output schema, the description adequately conveys the response contents (warranty_status, tenants, scores) and the importance of client UUIDs for downstream tools. It does not describe pagination structure or error behavior, but for a list tool with clear parameter docs, the missing details are minor. It is sufficiently complete for an agent to call it correctly.

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

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

Schema description coverage is 100%, so all parameters are documented in the schema. The description adds minimal extra value: it mentions the distributor usage for partner_uuid, but that is already in the schema. It does not elaborate on page/page_size semantics beyond what the schema provides. This sits at the baseline 3 for 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 opens with a clear verb ('List') and a specific resource ('clients') and enumerates the exact fields returned (warranty_status, integration tenants, 10 most recent Cork Cyber Scores). It also names the sibling cork_get_client_score_history as the alternative for older/date-bounded scores, distinguishing itself without ambiguity.

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

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

It explicitly states when to use an alternative ('For older scores or a bounded date range, use cork_get_client_score_history') and when this tool is a prerequisite (Client UUIDs required by five other tools). It also conditions the partner_uuid parameter on the API user being a distributor, giving clear contextual guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses output ordering, range inclusivity, and the limitation of the sibling list tool, but it does not describe pagination behavior beyond what the schema implies, nor whether the response contains the full history or only a page. It also does not mention rate limits or failure 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 compact, front-loaded with the core behavior, and every sentence adds useful information: history scope, ordering, category breakdown, date semantics, differentiation from cork_get_clients, and a prerequisite.

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 no annotations, the description covers the main surface: what is returned, ordering, optional filters, and the source of the required parameter. It is missing explicit details about response shape and pagination semantics, but the parameter descriptions and the tool's simple list nature make this a minor gap rather than a critical one.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description does add context about why the date bounds exist and that they are inclusive, which is useful, but it does not substantially deepen parameter semantics 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 states the tool returns a client's full Cork Cyber Score history, ordered newest first, with risk points per category. It distinguishes itself from cork_get_clients, which only provides the 10 most recent scores, so the purpose is specific and non-overlapping with siblings.

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

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

The description explicitly explains when to use this tool: for trend reporting and to retrieve more than the 10 recent scores available from cork_get_clients. It also states the prerequisite of obtaining a client UUID from cork_get_clients, and explains the inclusive date-range semantics.

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 present, so the description carries the behavioral burden. It discloses default exclusions (resolved events excluded by default), how to include them, and the meaning of at_risk=true. It could mention pagination or ordering, but the key behavioral defaults are effectively surfaced.

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 concise sentences: purpose, filter options, and default behavior. Every sentence adds useful information without redundancy or filler, and the most important usage details are 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 14-parameter tool with no output schema and no annotations, the description supplies the crucial behavioral defaults and cross-references for valid values and UUID sources. It is not exhaustive (no example output or sorting info), but it gives an agent enough to call the tool effectively.

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 high (86%), which sets the baseline at 3. The description adds value beyond the schema by tying event_type to a sibling tool, clarifying the resolved-event default behavior, and reinforcing the show_resolved requirement for resolved date filters. It doesn't describe every parameter, but the schema already handles those.

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?

Description uses a specific verb ('List') with a clear resource ('policy violations and risk events detected for a client's assets'), which distinguishes it from sibling tools like cork_get_compliance_event_types and cork_get_compliance_notification_settings. An agent immediately understands what this tool returns.

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?

Description gives concrete filtering guidance: use cork_get_compliance_event_types for valid event_type values, set at_risk=true for active risks, and set show_resolved=true to include resolved events. It doesn't explicitly mention when not to use this tool versus alternatives, but the read/list purpose is clear enough for routing.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It clearly signals a read-only listing operation and states what the returned data contains ('descriptions and cure periods'). It does not mention side effects, auth requirements, or pagination, but for a zero-parameter list tool these are less critical.

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

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

Two short sentences deliver both the purpose and the intended use case with no wasted words. The core action is front-loaded and the usage guidance is directly attached.

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 discovery tool with no output schema, the description is complete: it states what is returned and why an agent would use it. Nothing needed to invoke the tool correctly is missing.

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

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

The tool has zero parameters, so the schema is complete and there is nothing to document. The description adds useful context by explaining that the output values are meant to be used as event_type filters elsewhere, which aids correct usage.

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

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

The description uses a specific verb ('List') and resource ('compliance event types'), and clarifies that the result includes descriptions and cure periods. This clearly distinguishes it from the sibling cork_get_compliance_events, which deals with events rather than event types.

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

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

The description explicitly states when to use the tool: 'Use to discover valid event_type values before filtering cork_get_compliance_events.' This gives an agent actionable guidance for selecting this tool over the related events 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?

No annotations are present, so the description must disclose behavioral traits on its own. It only states the operation is a 'List' (implying read-only) but does not mention pagination behavior, response size limits, potential filters, or any side effects. The extra clause describes response content, not behavior.

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

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

The description is a single, readable sentence that front-loads the core purpose. The trailing clause adds useful specificity without being verbose, though it partially restates 'notification and alerting rules.'

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 six parameters, half lacking descriptions, and no output schema or annotations, the description leaves important gaps: it does not mention paginated list responses, the meaning of optional filters, or the structure of the returned rules. A tool this complex needs more operational context.

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

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

Schema coverage is only 50%, so the description must compensate for undescribed parameters like inbox_uuid, device_uuid, and domain_uuid. It does not explain their meaning or how they refine the query; the phrase 'on a client's assets' only hints at asset filtering. No parameter-level insight is added.

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

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

The description states a specific verb ('List') and a specific resource ('notification and alerting rules configured for compliance events'), and distinguishes itself from sibling event-listing tools by clarifying that it returns rules, not the events themselves. The dash clause adds specificity about event types and routing.

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

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

No guidance is given on when to use this tool versus alternatives like cork_get_compliance_events or cork_get_compliance_event_types. The description implies a use case (retrieving notification rules) but provides no exclusions, prerequisites, or decision 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 behavioral burden. It discloses the shape and semantics of the return data, especially the RMM installer block, and 'List' clearly signals a read-only operation. It does not discuss auth or errors, but no hidden side-effect or surprising behavior is apparent for this tool.

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

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

Three purposeful sentences: the first delivers the core purpose, the second adds the unusual RMM-specific output detail, and the third connects the tool to sibling workflows. No filler, and the most important 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?

The description covers what the list contains, its unique RMM installer semantics, how to combine it with cork_get_client_devices, and which sibling tools consume the resulting UUIDs. No output schema exists, but the description sufficiently characterizes the return value and the invocation context.

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

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

Schema coverage is 100% for all three parameters, so the schema fully documents page, page_size, and partner_uuid. The description adds no parameter-level meaning beyond what the schema already provides, which matches 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?

States a specific verb ('List') and a clear resource ('integrations connected to Cork'), then enumerates distinguishing content (vendor, connection status, sync details, installer block). The phrase 'connected' differentiates it from the sibling cork_get_available_integrations without ambiguity.

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

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

Provides clear usage context: use with cork_get_client_devices to map device connections and use the result to feed UUIDs into three downstream integration tools. It stops short of explicitly stating when NOT to use it, but the context is strong enough for an agent to route correctly.

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

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

With no annotations, the description compensates by explaining the state taxonomy and the critical caveat that 'success' means RMM acceptance, not completed on-device installation. It also specifies ordering, but doesn't go into authorization or whether any side effects occur, though 'List' strongly implies read-only.

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 purpose, ordering, return fields, filtering, and a non-obvious success definition without waste. The most important caveat is placed at the end but stays tightly integrated.

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?

Even without an output schema, the description lists the meaningful return contents and disambiguates state semantics. Combined with fully documented parameter schema, an agent has what it needs 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?

Schema description coverage is 100%, so the schema already documents all five parameters fully. The description reinforces the filtering by client/device but adds little 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 names a specific verb ('List') and resource ('past software install attempts') with explicit ordering and included fields. This clearly distinguishes it from sibling tools like cork_get_installer_setup, which targets setup configuration rather than history.

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?

States the tool is for retrieving install history and offers filtering by client_uuid/device_uuid, establishing clear context. It does not explicitly compare to alternatives or state when not to use it, so it stops short of a 5.

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

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

With no annotations, the description carries the behavioral disclosure burden. It implies a read-only lookup by using 'get' and describing returned content, but it does not explicitly state that the operation has no side effects, whether authentication is required, or what happens when setup is not needed. The description adds meaningful context but leaves some behavioral aspects implicit.

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 but information-dense sentence, front-loading the core purpose and then the trigger condition. It is reasonably concise and avoids redundancy, though the long dash-separated enumeration makes it slightly harder to parse than necessary.

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 two fully documented parameters and no output schema, the description covers the essential return contents and the exact usage condition. It is complete enough for an agent to invoke the tool correctly, though it could mention possible empty/undefined results when setup is not required.

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

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

Schema description coverage is 100%, so the schema already documents both vendor_key and package_manager_key well. The description mentions the package manager in the usage condition but does not add new parameter-level 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 clearly identifies the tool's purpose: retrieving one-time setup steps for RMM vendors that require manual setup before software installs work. It specifies what is returned (script to create, exact name, settings, variables) and distinguishes itself from sibling read tools via the manual-setup 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 an explicit trigger condition: use it when installer.requires_manual_setup=true and the package manager is missing from installer.configured_package_managers. It does not explicitly mention when not to use it or name alternatives, but the provided context is strong enough for an agent to route correctly.

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

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

With no annotations, the description carries the burden of explaining behavior. It does disclose the scope ('devices that have been mapped') and the kind of data returned, which is useful. However, it does not state that the operation is read-only, whether pagination affects results, or any limitations/conditions beyond 'mapped.'

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

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

A single front-loaded sentence conveys the action, scope, and result fields without redundancy. Every phrase earns its place, and the 'mapped' qualifier is essential.

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/list operation, the description covers the main output categories and the mapping filter, while the schema covers pagination and the integration UUID source. Missing context such as the meaning of 'mapped' and relationship to tenant_uuid keeps it from being fully complete, but it is adequate for basic 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 schema already documents page, page_size, and integration_uuid with 75% coverage, so the description does not need to repeat them. The description adds little param-specific meaning beyond the schema; tenant_uuid remains undocumented by both the schema and description.

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

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

The description states a specific action ('List devices observed from an integration') and enumerates the key content (hostnames, IP addresses, device properties, normalized OS details), making the core purpose clear. It is distinct from siblings like cork_get_client_devices by the 'integration' scope, though it does not explicitly name that sibling.

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

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

No guidance is provided about when to use this tool versus cork_get_client_devices, cork_get_connected_integrations, or other sibling tools. The 'from an integration' phrase implies a use case, but there are no stated conditions, exclusions, or alternatives.

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

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

No annotations are provided, so the description carries the behavioral burden. The verb 'List' implies a read-only operation and 'observed from an integration' adds data-source context. However, it does not disclose pagination behavior, data freshness, or what 'observed' means operationally, though these are less critical for a simple listing tool.

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

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

The description is a single, front-loaded sentence with no filler. It efficiently states the action, the returned resource, and the source context.

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

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

The required integration_uuid dependency is clear enough to make a basic call, but the optional tenant_uuid filter is unexplained and there is no output schema to indicate what tenant fields are returned. For a list tool with four parameters, the definition is adequate but leaves meaningful gaps.

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 describes page, page_size, and integration_uuid, but tenant_uuid has no description and the tool description adds no clarification. The phrase 'from an integration' is largely redundant with the schema's integration_uuid description, leaving one parameter semantically unexplained.

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

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

The description uses a specific verb and resource: 'List customer tenants observed from an integration.' This clearly distinguishes the tool from siblings like cork_get_integration_users and cork_get_integration_devices by focusing on tenant-level data sourced from an integration.

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

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

No guidance is provided on when to use this tool versus alternative getter tools. The description states only what the tool does, with no mention of when-to-use conditions, exclusions, or related integrations such as cork_get_connected_integrations or cork_get_integration_users.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action. It does not disclose read-only status, pagination behavior, filtering semantics, or response shape; 'observed' hints at passive collection but is not a substantive 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 a single front-loaded sentence with no filler or redundant phrasing. Every word earns its place, though the extreme brevity does trade away deeper context covered by other dimensions.

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 paginated list tool, the schema plus this one-line description provides enough to make a basic call: the required parameter is documented and the resource is clear. However, with no output schema and no annotations, the agent still lacks information about response contents, tenant scoping, and why to prefer this tool over sibling getters.

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

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

The schema already documents page, page_size, and integration_uuid, including saying where integration_uuid comes from, so the description need not repeat those. It adds no extra meaning over the schema and leaves tenant_uuid's role unexplained, so a middle score 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 clear verb ('List') and a specific resource ('users observed from an integration'), so an agent can tell what operation is being offered. It does not explicitly contrast itself with sibling tools like cork_get_integration_devices or cork_get_integration_tenants, which keeps it from a 5.

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

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

The phrase 'from an integration' implies this tool is for integration-scoped user listing, and the schema points to cork_get_connected_integrations as the source of the UUID. However, the description itself gives no explicit when-to-use/when-not-to-use guidance or alternatives, so usage context is only implied.

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

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

With no annotations provided, the description carries the full behavioral burden and does so excellently. It discloses that only nonzero-billed items are returned, that discount items appear as negative totals, and that sub-items are nested with total_billed always 0. These are exactly the surprising behaviors an agent needs to know before invoking the tool.

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

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

Three focused sentences, each adding distinct value: primary purpose, filtering/negative-total behavior, and nesting/zero-total behavior. The most important information is front-loaded and there is no filler.

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

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

For an input schema that already documents all parameters, the description provides rich semantic context about output composition and edge cases. However, since there is no output schema, the description does not enumerate the other likely line-item fields beyond total_billed and children, which leaves a minor completeness gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The description confirms the invoice_uuid source but this is already stated in the schema; it adds no new parameter-level detail about page or page_size behavior beyond what the schema provides.

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

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

The description states a clear verb+resource pair ('List billed, top-level line items for an invoice') and immediately ties it to the sibling cork_get_invoices, which prevents confusion with the parent invoice tool. It also adds decisive scope details: nonzero totals, discount line items, and nested sub-items.

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 when this tool is relevant: after obtaining an invoice via cork_get_invoices, to inspect its billed line items. It does not explicitly enumerate exclusions or alternatives, but the context is strong enough that an agent can infer the right call path.

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 behavioral disclosure burden. It discloses the listing behavior, the UUID output purpose, and the distributor/partner_uuid scoping nuance, but it does not mention pagination behavior, response format, or error/authorization handling.

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

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

Three short sentences, each adding distinct value: what the tool lists, what it returns and why, and when a specific parameter is needed. There is no filler or redundancy.

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

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

For a simple list tool with only optional parameters, the description plus schema is enough to invoke it correctly. Minor gaps like response envelope and non-distributor partner_uuid behavior exist, but they do not block successful use.

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

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

The schema already describes page and page_size, and the description adds meaning to the otherwise undocumented partner_uuid by explaining the distributor condition and scoping behavior. This compensates for the 67% schema description coverage.

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

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

The description states a specific verb ('List') and resource ('billing invoices'), then clarifies the output as invoice UUIDs needed by cork_get_invoice_line_items. This clearly distinguishes it from the sibling line-items 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?

It provides concrete usage context: list invoices to obtain UUIDs for the downstream line-items tool, and if the caller is a distributor, scope with partner_uuid. It does not explicitly mention when not to use it or name a direct alternative, so it stops short of a 5.

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

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

With no annotations, the description carries the behavioral burden. It discloses the return value type (partner UUIDs), the account-type restriction, and onward usage. However, it does not explicitly state side-effect-free read behavior, pagination response format, or potential empty results. 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?

Two succinct sentences deliver the core purpose, return value usage, and access constraint with no filler. Information is front-loaded and every sentence earns its place.

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

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

For a simple list tool with two optional pagination parameters and no output schema, the description gives enough to call it correctly: what it lists, who may use it, and what to do with the results. It stops just short of describing the full response envelope or read-only nature, but those are minor gaps.

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

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

The input schema already documents page and page_size with descriptions, so schema coverage is 100%. The description does not need to add parameter details; it adds contextual value about how the returned data is used, but not about the parameters themselves.

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

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

The description states a specific verb and resource ('List partner sub-accounts managed by this distributor') and adds a key scoping behavior: returns UUIDs for use in other tools. This clearly distinguishes the tool from sibling tools focused on clients, devices, and integrations.

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

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

The description explains why an agent would call this tool (to obtain partner_uuid values for later scoping) and includes a constraint ('Distributor accounts only'). It does not explicitly name an alternative tool for non-distributors, but the context 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by clarifying that this is a non-installing, listing-only operation and that returned package_id values are meant for later dispatch. It could add more about pagination or other response traits, but the schema already covers pagination parameters.

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

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

The description is compact and well-structured: it states the core purpose first, then the filtering options, then the critical return-value/installation caveat. Every sentence earns its place 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?

Although there is no output schema and no annotations, the description explains the key return artifact (package_id) and the tool's boundary (no install). It is largely complete for a simple list-with-filters tool, though it could briefly mention the expected response shape beyond package_id.

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

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

Schema description coverage is 100%, so the schema already documents page, search, page_size, and package_manager_key. The description adds modest value by restating search as substring matching and package_manager_key as a filter, but it does not substantially expand 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 states the verb 'List', the resource 'software packages', and narrows the scope to supported package managers (WinGet, Chocolatey). It also distinguishes this tool from sibling inventory tools by framing the output as package_id values for future install dispatch.

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

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

The description explains the intended use case: listing installable packages and returning IDs for future install dispatch. It also clarifies that the tool does not perform installation itself, which prevents misuse. However, it does not explicitly contrast this with siblings like software vulnerabilities or installer history.

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 reveals the output fields and filter intent, implying a read-only listing operation. However, it does not mention pagination behavior, how filters combine (AND vs OR), default sorting, or any access/pre-requisites, leaving some ambiguity for a 12-parameter tool.

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

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

The description is two sentences with no wasted words. The first sentence establishes the core purpose and output, and the second provides actionable filtering guidance. All information contributes directly to understanding or invoking the tool.

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

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

For a tool with 12 parameters, no output schema, and no annotations, the description is serviceable but not fully complete. It covers primary output and key filters, yet omits the return envelope/pagination structure, sorting behavior, partner_uuid usage, and explicit differentiation from the summary sibling. More detail would be needed for fully confident autonomous invocation.

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

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

Schema coverage is 75%, with three enum parameters (sort_by, sort_direction, minimum_priority) lacking schema descriptions. The description adds value by grouping risk filters under a common intent ('focus on the highest-risk findings') and naming client_uuid/device_uuid as scoping options. It does not add meaning to pagination or sorting parameters, but those are somewhat documented in 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 states a specific verb ('List'), a clear resource ('individual software vulnerabilities'), and enumerates the output details (CVSS, EPSS, KEV status, impacted version). This clearly distinguishes it from the sibling cork_get_software_vulnerability_summary by emphasizing individual findings rather than an aggregate view.

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 usage context: it explains how to filter for high-risk findings via minimum_cvss_score, minimum_epss_score, minimum_priority, or only_known_exploited, and how to scope by client_uuid or device_uuid. However, it does not explicitly name alternatives like the summary tool or state when not to use this tool, so it stops short of a 5.

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

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

There are no annotations, so the description carries the full burden. It does disclose key behavior: grouping by product, counting devices/versions, and showing highest severity. However, it does not reveal default scoping when client_uuid is omitted, ordering behavior, or pagination characteristics.

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 with zero filler. The core purpose and output fields are front-loaded, followed immediately by scoping and follow-up guidance.

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 adequately explains the return shape (device counts, version counts, highest severity) and how to proceed for details. Minor gaps exist around default behavior without client_uuid and sort/pagination semantics, but these are acceptable for a read-only summary 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 71%, so most parameters are already documented. The description adds meaningful context for client_uuid ('scope to a single client') and clarifies the rollup semantics. It does not, however, add value for sort_by or sort_direction beyond their enum names.

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

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

The description uses a specific verb ('Get a rollup') and identifies a precise resource ('CVEs grouped by software product'), while listing the output fields (impacted devices, impacted versions, highest severity). It also names the sibling tool cork_get_software_vulnerabilities as the drill-down counterpart, making the distinction 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 instructs the agent to use client_uuid to scope to a single client and directs a follow-up to cork_get_software_vulnerabilities for CVE-level detail. This provides both when-to-use and an alternative, helping the agent select between the summary and the detailed sibling 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions that it lists active warranty packages but gives no details on read-only nature, pagination, error handling, rate limits, or return structure. It also doesn't describe what happens with no results or any side effects, which is a significant gap for an unannotated tool.

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

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

The description is two sentences with no wasted words. The primary purpose is front-loaded, and the second sentence adds a valuable cross-reference tip. It is efficient and structured well 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?

The tool has no output schema and only optional parameters. The description gives the core purpose and a cross-reference use case but does not explain what the response contains (e.g., fields of warranty packages) or any nuances like pagination behavior beyond the schema. For a simple list tool, it is adequate but lacks details about the return payload that an agent might need.

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

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

The input schema has 100% description coverage, with each parameter (page, page_size, partner_uuid) already documented. The description adds no parameter-specific information beyond what the schema provides. The reference to warranty_status is in another tool's schema, not relevant to this tool's parameters. Baseline 3 applies because the schema already handles parameter semantics.

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

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

The description states 'List active cyber warranty packages' – a clear verb and resource. It is specific enough to distinguish from sibling get tools, though it doesn't name an explicit alternative. The purpose is unambiguous and not a tautology.

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 concrete use case (identifying clients without warranty coverage) and points to cork_get_clients for cross-referencing. However, it does not explicitly state when to use this tool instead of other listing tools, nor does it mention when not to use it. The usage context 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 provided, the description carries the burden. It discloses that the call reflects the authenticated session context, which is useful. It doesn't describe the return format or whether this can fail on invalid credentials, but for a zero-parameter identity check the gap is modest.

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

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

A single efficient sentence that front-loads the purpose and follows with a practical use case. Zero 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 no-parameter read-only identity tool with no output schema, the description covers purpose and a usage scenario. The only omission is the return shape, but that is minor given the tool's simplicity and the sibling list makes its distinct role 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, so the description has nothing to document. Baseline 4 applies, and the description adds relevant context by naming what the returned info covers (identity, role, scope).

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

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

States a specific verb (get) and a clear resource (authenticated Cork user), and enumerates the exact fields returned (identity, role, partner/distributor scope). This distinguishes it from all sibling tools, which target specific resources like clients, partners, or invoices rather than the caller's own identity.

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?

Offers a concrete use case ('quick credential sanity check'), which implies the tool verifies the current session. However, it doesn't explicitly state when not to use it or name alternatives, though no sibling is a genuine alternative since all others query different resources.

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