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

Usefully discloses the underlying call (POST to /endpoints/groups/{org}/{group}/contents) and the membership semantics ("Re-adding an existing member is a no-op"), which is real context beyond annotations. However, it says nothing about the confirm="YES" gate or dry_run defaulting to true, which are the two behavioral facts that most affect a destructive-flagged mutation; the no-op claim also sits in mild tension with idempotentHint=false without being a direct contradiction.

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

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

Two tight sentences, purpose front-loaded, mechanics second, zero filler. The raw URL path is arguably the only expendable content.

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

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

Output schema and rich annotations are supplied, so the description need not explain return values. Still, for a destructive, open-world mutation with a confirmation gate, it should at minimum note the dry_run/confirm execution model and that the group must pre-exist.

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 the request body shape and, notably, mentions a `type` field in the payload that has no corresponding top-level schema property, but it does not explain the confirm/dry_run/response_format 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?

A concrete verb-plus-resource statement ("Add a single endpoint to an endpoint group") that is unambiguous and clearly distinct from the sibling action1_remove_endpoint_from_group. It never names a sibling or scoping rule explicitly, so it falls just short of a 5.

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

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

The intent is implied cleanly by the verb, but there is no explicit when-to-use guidance, no prerequisite stating the group and endpoint must already exist, and no routing away from nearby tools (move_endpoint, list_group_contents, remove_endpoint_from_group). An agent can infer the case but gets no confirmation.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds useful semantics: filters are case-insensitive and the time bounds are translated to Action1's timefrom/timeto. It says nothing about result ordering, cursor behavior, or result volume on a readOnly search, which would have raised this.

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 naming the endpoint, the optional time window, and the three filter families. No filler, and the most important scoping detail comes first.

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

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

With rich annotations, a full output schema, and 100% schema description coverage, the description only needs to add filter semantics, which it does. The remaining gap is sibling disambiguation against the other audit-log tools, so it is not quite complete.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes beyond the schema by specifying that substring filters are case-insensitive and that from_time/to_time are sent as timefrom/timeto. That clarifies matching behavior the schema only names generically ('Filter by user name').

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

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

States a specific verb+resource ('Search /audit/events') and enumerates the filter dimensions (time window, user, event, object). It does not differentiate itself from the closely named siblings list_audit_events, export_audit_log or get_audit_event, so an agent still has to infer the boundary.

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 presence of an 'optional' time window and substring filters implies the use case (narrowing a large audit log), but there is no explicit statement of when to prefer this over action1_list_audit_events, action1_export_audit_log, or action1_get_audit_event for single records. Usage is inferable rather than stated.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, and the description still adds real behavior: a scan cap with default, the meaning of has_more as uncounted instances beyond max_scan, and an approximate output size. It is honest about a limitation (no per-template breakdown) rather than overselling the aggregation.

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 dense sentences, front-loaded with what the tool does, then the truncation caveat and output size. Every sentence carries information; the phrasing is slightly telegraphic ('Instance lists carry no actions') but not wasteful.

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

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

With an output schema present, return values need not be described, and the description still covers the scan cap, truncation flag, output size, and the missing per-template dimension. The remaining gap is that org_id is optional (no required params) and the description never says what scope is used when it is omitted.

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, but the description adds meaning the schema lacks: the default value of max_scan (1000) is not declared in the schema, and the consequence of hitting the cap (truncated counts flagged by has_more) is explained. It says nothing about org_id scoping or response_format behavior.

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 gives a specific verb and resource — walks automation instances and returns counts by_status — which is clearly an aggregation, not a listing. It also pre-empts a likely confusion by stating there is no per-template count. It stops short of naming a sibling (e.g. action1_list_automation_instances) as the alternative for raw instances.

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

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

Usage is only implied: an agent can infer this is the tool for counts rather than individual instances, and the 'no per-template count' note hints at what to use elsewhere. There is no explicit when-to-use, when-not-to-use, or named alternative among the many sibling automation tools.

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

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

The description confirms the operation is a creation/write action and that a copy is made. Since the annotations already flag it as 'destructiveHint: true', the description mainly reiterates the action's result, adding moderate clarity without revealing hidden operational constraints.

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 extremely concise, using exactly what is needed: first, defining the core function, and second, defining the authorization context. 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?

Given the comprehensive nature of the schema and annotations, the description provides all necessary functional and authorization context for an agent to correctly identify and use 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?

With 100% schema description coverage, the schema already provides full semantic meaning for all parameters. The description's focus remains on the high-level function rather than parameter details, maintaining the baseline score.

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

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

The description is highly specific, clearly defining the action (Clone), the resource (Software Repository package), and the outcome (Creates a full copy under a new package ID). This makes it very easy for an agent to select this tool over related create or retrieval actions.

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?

By specifying the required permission ('Perm: manage_software_repository.'), the description provides critical usage guidance regarding the tool's authorized scope. This is necessary context for an agent to decide if it is permitted to invoke the tool in a given environment.

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

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

Annotations already declare destructiveHint=true, non-idempotent, and open-world behavior, so the safety profile is covered structurally. The description adds the real operational requirement (manage_roles permission), which is genuine value, but says nothing about what the clone inherits, whether users/assignments are copied, or that a preview/confirm cycle is required.

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, front-loaded with the action, with zero filler. The second sentence largely restates the first ('Clone a role' / 'creates a copy of an existing role'), a minor 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?

An output schema exists so return values need no explanation, and the schema covers the execution gates. Still, for a destructive mutation with openWorldHint, the description leaves open what the copy inherits and when cloning is preferable to creating, which an agent would need to choose confidently.

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

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

Schema description coverage is 100% and the schema itself documents dry_run (default true) and the confirm="YES" gate, so the description need not repeat them. It adds no parameter-level meaning beyond the permission note, so baseline 3 applies.

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

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

The description gives a specific verb (clone) plus resource (role) and clarifies it creates a copy of an existing role, which naturally separates it from siblings like create_role and update_role. It stops short of explicitly routing against those siblings, but the clone semantics are unambiguous.

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

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

There is no guidance on when to clone versus create a role from scratch, no prerequisites beyond the permission string, and no note about the dry_run/confirm workflow an agent must follow before executing.

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

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

Annotations already disclose destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the required permission ('approve_updates'), which is useful context. However, it does not mention the confirm="YES" gate or that dry_run defaults to a preview, both of which are important behavioral facts for a destructive bulk mutation.

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 short and front-loaded, but the first sentence is a verbatim restatement of the title and the second sentence repeats the same idea with slightly more detail. Removing the redundant title echo would make it tighter without losing content.

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

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

An output schema exists and annotations cover the safety profile, so the description does not need to explain return values. Still, for a destructive bulk mutation gated by confirm and dry_run, the description would benefit from noting that execution requires confirmation and defaults to preview mode.

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 every parameter is already documented in the schema, including the confirm and dry_run semantics. The description adds no parameter-level meaning beyond what the schema provides, which is acceptable at this coverage level but not above 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 that the tool manages approval status for multiple packages in bulk, which is a recognizable verb+resource combination. It is less precise than ideal because the opening sentence merely restates the title, but the second sentence adds the bulk-scope detail. There is no sibling approval tool to differentiate from.

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

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

There is no explicit guidance on when to use this tool instead of alternatives, no mention of prerequisites beyond the permission string, and no indication of when approval should be set to Approved vs Declined. The agent must infer the use case entirely from the purpose sentence.

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

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

Annotations already declare destructive=true, openWorld=true, and idempotent=false, and the description is consistent with that by saying it runs immediately. It adds the permission requirement, but omits the crucial safety flow baked into the schema: dry_run defaults to true and confirm="YES" is required to actually execute. Given annotation coverage, this is a partial contribution.

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?

It is short and front-loaded with the action, which is good, but the second sentence is grammatically broken and cut off ('in the specified.'), wasting the one sentence that should carry scope and target detail.

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

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

An output schema exists, so return values needn't be explained, and the schema fully documents parameters. Still, for a destructive, non-idempotent batch execution tool with nested action objects, the description should mention the preview-by-default/confirm-to-execute behavior and the fact that endpoints accepts groups as well as individual endpoints.

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

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

Schema description coverage is 100% and every nested field (name, actions, endpoints, retry_minutes, org_id, confirm, dry_run) is documented in the schema itself. The description adds no syntax, format, or constraint detail beyond what the schema already states, so baseline 3 applies.

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

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

The second sentence gives a real verb+resource: it 'immediately runs an instance of the automation' on endpoints, which is clearer than the vague 'Apply a automation'. However the sentence is truncated ('in the specified.'), and nothing distinguishes this from siblings such as action1_execute_and_wait, action1_create_automation_schedule, or the individual run_script/deploy_update tools.

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

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

It supplies the required permission ('Perm: run_automations'), but gives no when-to-use guidance, no exclusions, and no routing to alternatives like creating a schedule instead of running immediately. The agent must infer that this is the one-shot execution path from the name alone.

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

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

Annotations already disclose non-readOnly, destructive, non-idempotent, and open-world behavior. The description adds an important authorization requirement, 'Perm: manage_automations', and endpoint execution scope, but it does not elaborate on destructive effects or the confirm/dry-run safeguards beyond what the schema already documents.

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 short and front-loaded with the core action. The first two sentences are slightly redundant, but overall it is efficient and wastes little space.

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

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

With a full input schema, an output schema, and rich annotations, the description does not need to explain return values or parameter details. It supplies the permission requirement and endpoint scope, though it still leaves schedule-vs-instance routing implicit for a complex destructive creation tool.

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

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

Schema description coverage is 100%, so the input schema already documents the parameters in detail. The description only echoes endpoint targeting and permission, adding little semantic meaning beyond the structured schema.

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

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

The description uses a specific verb, 'Create', and resource, 'automation schedule', and adds that the automation runs against a specified endpoint list plus the required permission. It is clear on its own, but it does not explicitly distinguish this tool from siblings such as action1_create_automation_instance or action1_update_automation.

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

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

The description states the required permission and that execution targets endpoints, which gives useful usage context. However, it does not say when to choose this schedule-creation tool over alternatives like creating an automation instance or updating an existing automation, nor does it provide exclusions.

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

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

The annotations already declare destructiveHint=true, openWorldHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered. The description adds the useful permission requirement, but it does not elaborate on the destructive nature of the operation, the confirm/dry_run execution flow, or what happens to existing remediation data.

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

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

It is very short and front-loaded: the core action is stated first, followed by the permission constraint. Nothing is wasted, though the extreme brevity leaves important usage context unstated.

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

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

With a rich input schema, an output schema, and annotations covering the safety profile, the description does not need to explain parameters or return values. However, for a destructive mutation with a required confirm token and a dry_run default, the description is thin on the operational context an agent would need to invoke it confidently.

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

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

Schema description coverage is 100%, so the schema already explains cve_id, body, org_id, confirm, and dry_run. The description adds no parameter-level meaning beyond what the schema provides, which is the expected baseline when schema coverage is high.

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 gives a specific verb and resource: documenting applied compensating controls for a specific vulnerability. It is clear what the tool does, but it does not distinguish this create operation from sibling remediation tools such as action1_update_remediation, action1_delete_remediation, or action1_list_cve_remediations.

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 names a required permission (manage_vulnerabilities) but gives no guidance on when to use this tool versus the sibling remediation tools. There is no mention of prerequisites beyond permission, no exclusions, and no indication of how this relates to listing or updating existing remediations.

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

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

Annotations already flag destructiveHint=true, readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful context — data sources are enterprise-wide and the caller needs the manage_data_sources permission — but omits the two-step dry_run/confirm='YES' behavior, which is the most consequential operational detail.

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, front-loaded with the action, and the permission note is a useful trailing cue. The opening two sentences are redundant with each other, a small waste of space.

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

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

For a destructive, non-idempotent creation tool with a required confirm='YES' parameter and a dry_run default of true, a description that never explains execution vs preview leaves the agent at real risk of a failed or unintended call. Output schema richness offsets this only partly.

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 nested body fields and the confirm/dry_run parameters are all documented in the schema. The description adds no parameter-level meaning of its own and never mentions confirm or dry_run.

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

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

States a specific verb+resource ('Create a data source' / 'Creates a new custom data source') that clearly separates it from the list/get/update/delete_data_source siblings. The second sentence is largely a restatement of the first, so it stops short of a 5.

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

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

No guidance on when to create a data source versus reusing an existing one, and no mention of the preview/confirm workflow that governs actually executing this call. The agent must infer everything from the schema.

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

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

The description is consistent with the provided annotations (destructiveHint: true). Since the name and function already strongly imply the destructive nature of creation, the description adds very little unique behavioral context beyond what is already captured in the annotations and title.

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 definition is highly efficient. Each sentence serves a purpose: identifying the action, specifying the resource and scope, and listing the necessary permissions. There is zero waste in the language used.

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

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

Despite having an extremely complex schema supporting detailed features like inclusion/exclusion filters, uptime alerts, and organization UUID management, the description is exceedingly brief. It fails to mention the tool's capacity for complex rule-based configuration, which is a key part of what makes this tool powerful.

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

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

With schema description coverage at 100%, the input schema fully defines all parameters (including complex filter structures). The description adds no semantic value to the parameters themselves, so the baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Create' and the resource 'endpoint group,' providing an unambiguous purpose. This specific naming and verb clearly distinguishes it from sibling tools like `action1_list_endpoint_groups` or `action1_update_group`.

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 tool specifies the required permission ('Perm: manage_endpoints'), which helps guide usage. However, it lacks explicit guidance on when to use this tool versus other creation or configuration tools, making the guidance minimal.

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

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

Annotations already declare destructiveHint=true, openWorldHint=true, idempotentHint=false, so the safety profile is covered. The description adds the required permission (remote_connect), which is genuine context beyond annotations, but says nothing about reversibility, the confirm gate, or what the session creates.

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?

It is short and front-loaded, but the second sentence is pure redundancy ("Sends a request to the endpoint to start a new remote session") and the permission note is tacked on rather than structured.

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

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

Output schema exists and schema coverage is complete, so return values and parameter details are covered elsewhere. Still, for a destructive, open-world creation call, the description omits the confirm="YES" execution gate and the dry_run default-to-preview behavior that most affect correct invocation.

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

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

Schema description coverage is 100%, so every parameter (endpoint_id, org_id, body.connection_type, confirm, dry_run) is already documented in the schema. The description mentions no parameters at all, so baseline 3 is appropriate.

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

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

The first sentence states a specific verb and resource (start a remote session) that an agent can act on. However, it never differentiates from its close siblings get_remote_session and update_remote_session, and the second sentence merely restates the first with extra words.

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 only guidance is "Perm: remote_connect," which is a permission prerequisite rather than when-to-use guidance. Nothing indicates when to open a session versus inspecting one with get_remote_session, nor any warning about the destructive/open-world nature of the call.

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

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

Annotations already declare destructiveHint=true, openWorldHint=true, idempotentHint=false and readOnlyHint=false, so the mutation risk profile is known. The description adds one genuinely useful piece of context — the required permission scope — but says nothing about side effects, whether the caller becomes an org admin, or irreversibility beyond what annotations imply.

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 fragments, one of which is a pure duplicate of the opening sentence. The redundancy wastes the most salient position in the description and pushes the only useful detail (the permission) to the tail.

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

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

With an output schema present and full schema coverage of the confirm/dry_run workflow, the description need not explain returns or parameters. It is minimally adequate, but for a destructive create-org operation it omits any note on scope of effect (e.g. does this create under the current enterprise) or what the required body fields mean.

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

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

Schema description coverage is 100% and the schema itself documents the body fields plus the two-step safety mechanism (confirm="YES", dry_run defaulting to true). The description adds no parameter-level meaning, so baseline 3 applies.

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

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

The verb+resource ("Create an organization") is unambiguous and implicitly distinguishes it from update_organization/delete_organization among siblings. However, the second sentence ("Creates a new organization") merely restates the first, adding zero information, and there is no explicit differentiation from siblings such as list_organizations or create_user.

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 only guidance is the permission requirement "Perm: manage_organizations." There is no statement of when to use this versus update_organization, what preconditions exist (e.g. name uniqueness), or any when-not-to-use guidance.

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

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

Annotations already declare destructiveHint=true, openWorldHint=true, and idempotentHint=false, so the safety profile is covered. The description adds useful context—the required permission ('manage_software_repository') and the fact that no versions are created—but does not explain the confirm/dry_run workflow or what 'set its initial basic' means.

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

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

The description is front-loaded with the action and resource, and it is reasonably concise. The phrase 'set its initial basic' is awkward and slightly unclear, keeping it from a perfect score, but there is no wasted text.

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 output schema and 100% schema description coverage, the description covers the core purpose and permission requirement. However, it omits explanation of the confirm/dry_run execution safety mechanism and leaves 'initial basic' undefined, so it is only minimally complete for a creation tool with nested payload.

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 parameters including the nested body fields. The description contributes no additional parameter details beyond the vague phrase 'set its initial basic', so the baseline score of 3 is appropriate.

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

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

The description states a specific verb ('Create') and resource ('Software Repository package object'), and clarifies it creates the package 'with no versions', which distinguishes it from action1_create_package_version. It does not explicitly name alternatives, but the scope detail is sufficient to separate it from most 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 provides no guidance on when to use this tool versus alternatives like action1_clone_package or action1_create_package_version. The only additional context is the required permission, which is not a usage guideline.

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

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

Annotations already disclose destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the required permission (manage_software_repository), which is genuinely useful context, but says nothing about what gets destroyed, whether duplicates fail, or the confirm/dry_run gating that governs execution.

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 second sentence is a near-verbatim restatement of the first ('Create new version...' / 'Adds a new version to the specified...'), so roughly half the text does no work. What remains is front-loaded 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?

Output schema exists, so return values need not be explained, and parameters are fully described in schema. However, for a destructive creation tool with a polymorphic OS-specific body (Windows vs. macOS variants) and a confirm/dry_run execution gate, the description gives no orientation to the two request shapes or the preview-first workflow, leaving the agent to discover both from the schema alone.

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 every parameter including the deeply nested body, org_id, confirm, and dry_run is already documented in the schema. The description adds no interpretation of its own, which is acceptable at baseline but not additive.

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 and resource (create a version inside a Software Repository package), which is unambiguous. It does not distinguish itself from close siblings such as action1_update_version or action1_create_package, so an agent must infer which one applies.

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

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

There is no guidance on when to use this versus action1_update_version, action1_create_package, or action1_clone_package. The only quasi-guidance is the permission string 'Perm: manage_software_repository', which states a prerequisite but not a selection rule.

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

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

Annotations already declare the mutation profile (readOnlyHint false, destructiveHint true, non-idempotent, open-world), so the bar is lower. The description adds meaningful context beyond them: the required 'manage_reports' permission and the fact that the report is placed in the predefined Custom report category.

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?

It is short and front-loaded with the action, then permission. There is slight redundancy between 'Create a custom report' and 'Creates a custom report in...', but otherwise every sentence carries information.

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

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

The tool is complex due to nested required body fields, but the 100% schema coverage and output schema mean the description need not restate body structure or return values. It supplies the essential permission and category context; only usage/alternative guidance is noticeably absent.

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

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

Schema description coverage is 100%, so the schema fully documents the body fields and the confirm/dry_run parameters. The description adds no parameter-level meaning beyond the schema, which is 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 states a specific verb and resource — 'Create a custom report' — and clarifies it lives in the predefined 'Custom report' category. It is distinguishable from list/get/update/delete report siblings, though it does not explicitly name an alternative such as create_report_subscription.

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 only guidance is 'Perm: manage_reports.' There is no statement of when to use this versus create_report_subscription or update_report, and no description-level mention of the preview/confirm workflow even though the schema requires a confirm string and defaults dry_run to true.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral fact not in the schema — the required permission 'view_reports' — but omits any warning about the destructive nature or the preview-then-confirm execution pattern.

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

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

The first two sentences are a verbatim duplication of the same statement, which is pure waste in a three-sentence description. Only the trailing permission note carries new information.

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

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

An output schema and rich annotations exist, so return values and safety signals are covered elsewhere. Still, for a destructive open-world mutation, the description should have explained the dry_run preview default and the confirm='YES' gate rather than leaving an agent to infer them from the schema.

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

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

Schema description coverage is 100%, so all three parameters (body with name/report_id/schedule, confirm, dry_run) are documented in structured data. The description adds nothing about parameter meaning, so the baseline of 3 applies.

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

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

The description states a clear verb and resource (create a report subscription), but it does so twice in nearly identical sentences, adding no specificity beyond the tool name and title. It does not distinguish this from sibling tools such as action1_update_report_subscription or action1_list_report_subscriptions.

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

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

There is no guidance on when to use this versus update_report_subscription or list_report_subscriptions, and no mention of prerequisites or the confirm/dry_run workflow. Only the permission string 'Perm: view_reports' offers any contextual hint.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the safety profile is covered. The description adds one genuine piece of extra context, the required `manage_roles` permission, but stays silent on the confirmation/dry-run execution gate that matters most for a destructive non-idempotent write.

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?

"Create a role. Creates a new role." is a duplicated statement; the second sentence earns no place. What remains is front-loaded but wasteful, and the space freed by removing the repetition could have carried the missing usage or safety 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?

An output schema exists and the input schema is fully documented, so return values and parameters need not be explained. Still, for a destructive write tool with role-related siblings, the description never states when to create versus clone or update, leaving a real 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 `body`, `name`, `description`, `scoped_permissions` and the `confirm`/`dry_run` flags are all self-documenting. The description adds nothing about the nested permission/scope structure, which is fine at this coverage level — baseline 3 applies.

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

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

The verb+resource ("Create a role") is unambiguous, but the description offers no differentiation from nearby siblings such as action1_clone_role, action1_update_role, or action1_create_role_user. An agent knows what it does but not how it differs from those alternatives.

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

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

There is no when-to-use guidance and no exclusions — nothing tells the agent to prefer clone_role when copying an existing role or update_role when modifying one. Only the permission prerequisite ("Perm: manage_roles") is stated, which is context but not usage 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?

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the safety profile is known. The description adds the required permission, which is genuine value, but stays silent on the preview-by-default behavior (dry_run defaults true) beyond what the schema already documents.

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

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

Front-loaded and short, but the second sentence largely restates the first ('Assigns user to a role specified by its ID') rather than adding information; only the permission clause earns its place.

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

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

With annotations, a 100% documented 4-param schema and an output schema, the essentials are covered. Still, the description omits the mutation's operational gate (dry_run preview plus confirm=YES) and the permission's effect on role scope, leaving a gap for a destructive write tool.

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

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

Schema description coverage is 100% and all four parameters are documented there, so the baseline is 3. The description only restates that the role is identified by ID and adds nothing on role_id format, user_id format, or interaßction with confirm/dry_run.

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

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

States a specific verb and resource ('Assign user to a specific role') plus the permission gate ('Perm: assign_roles'). It is distinguishable from sibling role tools like delete_role_user and list_role_users by the 'assign' verb, though it does not name those siblings explicitly.

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

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

Usage context is implied by the name and the stated permission prerequisite ('assign_roles'), which tells the agent a required capability. It gives no explicit when-to-use guidance and no mention of the dry_run/confirm two-step that governs actually executing the assignment.

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

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

Annotations already disclose that this is a non-readonly, destructive, non-idempotent operation. The description adds useful context with the required permission ('manage_scripts') and the destination ('Script Library'), but does not elaborate on duplicate handling, validation, or execution 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 short and front-loaded, with the action stated first. There is minor redundancy between 'Create a custom script' and 'Creates a new custom script,' but it remains efficient overall.

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 rich input schema, output schema, and annotations cover most call mechanics, including required body fields, confirmation, and dry-run behavior. However, the description omits usage context relative to sibling tools, leaving a gap for an agent deciding when to create versus update or run a script.

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 body, confirm, and dry_run. The description adds no parameter-level meaning beyond what the schema provides, making the baseline score of 3 appropriate.

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

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

States a specific verb and resource: 'Create a custom script' and clarifies it 'adds it to the Script Library.' The purpose is clear, though it does not explicitly differentiate this tool from siblings such as action1_update_script or action1_run_script.

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

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

The description gives no guidance on when to use this tool versus alternatives like update_script or run_script. It only notes the required permission, which is a prerequisite rather than usage context.

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

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

Annotations already disclose destructiveHint=true, openWorldHint=true, non-idempotent behavior, and readOnlyHint=false. The description adds useful context about the required permission and enterprise-wide template scope, but it does not mention the dry_run/confirm safety flow documented in the schema. There is no contradiction with the annotations.

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

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

The description is short and front-loaded, but the first two sentences are exact duplicates: 'Create a new setting. Creates a new setting.' That redundancy does not earn its place and makes the structure slightly wasteful.

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 definition provides sufficient context for a create mutation: purpose, permission requirement, and enterprise-wide template scope. The schema already covers the safety controls, and an output schema exists, so the description need not explain return values. It could be stronger with explicit guidance on dry_run versus confirm execution.

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

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

Schema description coverage is 100%, so the input schema already explains body, value, scope, template_id, confirm, and dry_run. The description adds no parameter-level details beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description clearly states a specific verb and resource: 'Create a new setting.' It also adds that setting templates are enterprise-wide, which gives scope context. It does not explicitly differentiate from update_setting, so it stops short of a 5.

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

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

The description implies this is for creating new settings and states the required permission, manage_advanced_settings. However, it gives no explicit when-to-use guidance versus update_setting or other siblings, and no exclusion conditions.

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

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

Annotations already declare destructiveHint=true, openWorldHint=true and non-idempotent, so the safety profile is covered. The description adds one genuinely non-structured fact — the required 'manage_users' permission — but says nothing about duplicate-email behavior, password handling, or how SSO creation differs, and the promised SSO documentation pointer is blank.

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 opening is wasted duplication ('Create new user. Creates a new user.') and the SSO sentence ends in a dangling 'documentation: -' fragment. Neither the permission line nor the broken reference is front-loaded in a way that helps invocation.

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

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

An output schema exists and annotations cover safety, so the description is not required to explain returns. However, for a destructive user-creation mutation it omits the SSO path it advertises, and the only unique behavioral detail (permission requirement) is a single trailing tag.

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

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

Schema description coverage is 100% and the nested body variants are documented, so the schema carries the parameter burden. The description adds no meaning to any parameter — even the SSO hint, which would plausibly relate to a body field, points at an empty reference.

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 verb+resource ('create user') is identifiable, but the first two sentences are the same statement repeated ('Create new user. Creates a new user.') and nothing distinguishes this from sibling user/role tools such as action1_create_role_user or action1_update_user. An agent knows what it does but not why it would pick this over its 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 only guidance offered is 'To create an SSO user, please first review the following documentation: -' where the link is empty, making the hint unusable. The 'Perm: manage_users' note tells the agent the required permission, but there is no when-to-use / when-not-to-use framing or mention of alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds real value on top by asserting 'Does NOT execute' and specifying the workflow handoff to action1_deploy_update. It could have noted scope requirements (org_id, or that cve_id/endpoint_id is an either/or selector), which is why it is not a 5.

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

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

Two sentences, front-loaded with the read-only correlation purpose and followed immediately by the non-execution constraint and handoff. 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?

With an output schema present and rich annotations, the description only needs to convey purpose and non-execution semantics, which it does. Minor gap: it doesn't clarify the cve_id-vs-endpoint_id selector logic, which matters for a tool with zero required parameters.

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

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

Schema description coverage is 100% with five well-documented parameters including enum and format constraints, so the baseline is 3. The description adds no parameter-level meaning, not even that cve_id and endpoint_id are alternative selectors or that org_id scopes the result.

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

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

States a specific verb+resource: correlating vulnerabilities with the updates that fix them, producing a plan. It also distinguishes itself from the execution sibling by naming action1_deploy_update. However, it never explicitly says it 'builds a plan' for a CVE or endpoint as the title does, and does not differentiate from near-neighbors like action1_list_cve_remediations or action1_create_cve_remediation.

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

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

Gives a clear use rule: it does not execute, and the result should be handed to action1_deploy_update. That is a genuine when-to-use and what-next statement. It stops short of stating when to prefer this over the other CVE remediation tools (list/create/update), so no explicit exclusions beyond the deploy sibling.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is largely covered. The description adds useful authorization context with 'Perm: manage_automations', but it does not explain the confirm/dry_run safeguards or irreversibility beyond what annotations provide.

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

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

The description is short and front-loads the action. The first two sentences overlap slightly by restating the delete operation, but the overall structure is efficient.

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

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

Given the annotations, full schema descriptions, and presence of an output schema, the definition contains the core information needed to invoke the tool. It could be stronger by mentioning the confirm/dry_run execution model, but that is already covered in the schema.

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

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

Schema description coverage is 100%, and the schema already documents automation_id, org_id, confirm, and dry_run in detail. The description only says the automation is specified by its ID, adding no meaning beyond the schema for the remaining parameters.

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

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

The description states a specific verb and resource: deleting a scheduled automation specified by its ID. This is clear and matches the title, though it does not explicitly distinguish the tool from the sibling action1_delete_automation_action.

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

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

The description gives no when-to-use guidance, no when-not-to-use guidance, and no alternatives. The only contextual note is the required permission, which does not help an agent choose between this and related automation tools.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description contributes the required permission (manage_automations), which is genuinely additive, but it never mentions the confirm="YES"/dry_run safety gate that governs actual execution, nor whether deletion is reversible.

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

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

The first two sentences say the same thing twice ('Delete an action from a automation' / 'Deletes a specified action from a scheduled automation'), wasting the most prominent position on a restatement of the title. The permission line does earn its place.

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

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

An output schema exists and the input schema is fully described, so the mechanical call requirements are covered. However, for a destructive tool with a mandatory confirmation string and a default-true dry_run, the description omits the operational flow that an agent most needs to avoid accidental deletion.

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 five parameters including confirm and dry_run are already documented in the schema. The description adds no syntax, default, or interaction detail beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource (delete an action) scoped to a scheduled automation, which distinguishes it from delete_automation and delete_package_version_action in the sibling list. It stops short of explicitly naming those siblings, so differentiation is inferential rather than stated.

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

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

There is no guidance on when to use this versus deleting the whole automation or other delete-* tools, and no mention of prerequisites beyond the permission string. The agent must infer the use case entirely from the name.

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

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

Annotations already cover destructiveness and idempotency, and the description adds meaningful context beyond them: the required permission (manage_data_sources) and the built-in-source restriction. It does not restate dry_run/confirm semantics, but those are documented 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 first two sentences say the same thing ('Delete a custom data source' / 'Deletes an existing custom data source'), wasting space. The permission and built-in constraints are useful, but the definition is not front-loaded or tight.

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

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

With an output schema present, annotations covering safety, and full schema coverage, the description supplies the remaining needed context: the built-in restriction and required permission. Sufficient for an agent to call correctly, though missing any explicit caution about irreversibility.

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

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

Schema description coverage is 100%, so all three parameters (data_source_id, confirm, dry_run) are already documented. The description adds no parameter-level meaning, which is acceptable at this coverage level but not value-adding.

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

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

States a specific verb and resource ('Delete a custom data source') that clearly identifies it against the create/get/update/list data source siblings. The first two sentences are redundant restatements, but the meaning is unambiguous.

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

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

Adds one useful precondition — built-in data sources cannot be removed — which implies when the call will fail. However, it offers no explicit guidance on when to use this versus alternatives (e.g., update_data_source to disable instead), leaving routing to inference.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered structurally. The description adds the concrete permission requirement (manage_endpoints), which is genuinely useful context, but is silent on the confirm="YES" gate and dry_run default that make this delete irreversible in practice.

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 fragments with no wasted words, but the terseness comes at the cost of under-specification rather than economical clarity. The permission note could have been paired with a single clause on confirmation behavior at no length cost.

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 destructive delete with an output schema and a confirm="YES" safeguard, the description gives the agent only the permission and nothing about the two-step confirmation flow or irreversibility. An agent reading just this description would not know a confirmation string is required to actually execute.

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%, including inline docs for deployer_id, confirm, dry_run, and org_id, so parameter meaning is fully carried by the schema. The description adds nothing beyond the permission note, which is the expected baseline when the schema does the heavy lifting.

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

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

The text 'Delete Deployer' simply restates the tool name and title verbatim, adding no scope, target, or effect detail. It does distinguish the verb 'delete' from the read-only deployer siblings (get_deployer, list_endpoint_deployers), but the statement itself is tautological.

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?

'Perm: manage_endpoints' tells the agent the required permission but says nothing about when to use this tool versus alternatives, nor when not to delete a deployer. No prerequisite or context is given beyond the permission string.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds genuine value by disclosing the agent-uninstall side effect and the required 'manage_endpoints' permission. However, it omits that dry_run defaults to true and that confirm="YES" is required — critical execution behavior for a destructive action.

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, front-loaded with the action, with no filler. The permission clause earns its place; only minor loss for not surfacing the dry_run/confirm workflow in the same compact form.

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 destructive tool with an output schema present, the return values need not be explained, but the description should flag the preview-by-default and confirmation-string workflow an agent must follow before deleting. That gap leaves it adequate but incomplete.

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

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

Schema description coverage is 100% and all four parameters are documented in the schema, so the baseline of 3 applies. The description adds no parameter-level detail beyond what is already 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?

States a specific verb+resource ('Delete an endpoint') and adds scope by clarifying that it also attempts to uninstall the endpoint's agent. It's clearly distinguishable from siblings like action1_delete_group, action1_delete_deployer, or action1_update_endpoint, though it doesn't explicitly name them.

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

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

No when-to-use or when-not-to-use guidance, and no mention of the required confirm="YES" gate or the dry_run default of true, which are the key decision points for invoking this destructive tool. The agent is left to discover the two-step preview/execute workflow from the schema alone.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, so the risk profile is covered structurally. The description adds the required permission ('Perm: manage_endpoints'), which is genuine extra context, but it omits the two-step safety protocol (confirm must be exactly "YES", dry_run defaults true) and says nothing about cascading effects on member endpoints.

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

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

Front-loaded with the verb+resource, which is correct. However, sentence two ('Deletes an existing group in the specified organization') largely restates sentence one, and the permission tag trails as a fragment — the space would be better spent on consequences or the dry-run/confirm workflow.

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?

Output schema and rich annotations mean return values and safety posture need not be described. But for a destructive group deletion, the description should disclose what happens to endpoints assigned to the group and how the confirm/dry_run guard works — that context is only implicit in the schema.

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

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

Schema description coverage is 100%, so all four parameters including confirm and dry_run are already documented in the schema. The description adds no parameter-level meaning beyond that, which is the expected baseline when the schema carries the load.

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

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

States a specific verb and resource ('Delete an endpoint group'), and the sibling list makes the target unambiguous — this is clearly not action1_delete_endpoint, action1_update_group, or action1_delete_deployer. It does not explicitly name an alternative, but the resource noun does the disambiguating work.

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 on when to delete a group versus updating it or removing endpoints individually, and no mention of prerequisites or consequence (e.g., what happens to endpoints still in the group). The presence of confirm/dry_run params implies a guarded workflow the description never explains.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false, so the agent knows this is an irreversible-style mutation and safe to retry. The description adds the required permission, which is genuinely useful, but says nothing about cascading effects (do the org's endpoints/users go with it?) or recoverability.

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, front-loaded with the action and permission last. "Removes an organization from the enterprise" is mild restatement of the first sentence, but nothing is verbose or padded.

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

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

An output schema exists and the annotations carry the safety profile, so return values and risk are covered elsewhere. The one substantive gap is whether deletion cascades to child resources, which an agent deciding to call a destructive tool would want to know.

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 org_id, confirm, and dry_run are fully documented with their constraints. The description adds no parameter-level meaning beyond the schema, which is acceptable at this coverage level.

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?

Specific verb + resource ("Delete an organization") with a clarifying scope sentence ("Removes an organization from the enterprise"), which cleanly distinguishes it from update_organization and create_organization among the siblings. It stops short of explicitly naming the adjacent tools, but the operation is unambiguous.

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

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

Provides one prerequisite ("Perm: manage_organizations") but gives no guidance on when deletion is appropriate versus alternatives such as removing members or updating the org, and no warning about irreversibility. The dry_run/confirm guardrails exist only in the schema, not in the description.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered structurally. The description adds the required permission, which is genuinely useful context. However, for a destructive operation it says nothing about irreversibility or the dry_run-defaults-to-preview / confirm-required gate, which is the most important behavioral detail here.

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 second sentence largely restates the first, adding only the permission note. Front-loaded and short, but one of two sentences is redundant.

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

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

An output schema exists and annotations carry the risk profile, so the bar is moderate. Still, a destructive deletion tool whose description omits the preview/confirm semantics and any warning about irreversibility leaves a meaningful gap for an agent deciding whether to call 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 all four parameters (org_id, confirm, dry_run, package_id) are already documented in the schema. The description's 'specified by its ID' merely echoes package_id; baseline 3 applies.

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

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

States a specific verb and resource (delete a custom Software Repository package), plus the identifier used to target it. It is distinguishable from nearby siblings such as action1_delete_package_version_action and action1_delete_version, but the description never explicitly draws that line, so it stops short of a 5.

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

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

The only guidance is 'Perm: manage_software_repository.' There is no statement of when to use this versus deleting a version or the package-version action, and no mention of the preview-then-execute flow that governs this destructive tool. An agent gets no routing or precondition help.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true. The description adds the required permission ('manage_software_repository'), which is genuinely useful authorization context. However, it doesn't mention the confirm="YES"/dry_run safety flow, which matters for a destructive operation.

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 terse sentences, front-loaded and free of filler. Tight, though one sentence is a near-verbatim echo of the title.

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

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

With a rich output schema and full annotation set, the essentials are covered. Still, for a destructive multi-ID operation it omits any note about irreversibility or the preview-by-default behavior that an agent calling this should account for.

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

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

Schema description coverage is 100%, so all six parameters are documented in the schema. The description adds no parameter semantics beyond that, which is acceptable given the schema does the heavy lifting.

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

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

Specific verb+resource: deletes an 'additional action' from a version of a Software Repository package. Clear enough to invoke, though it just restates the title and doesn't distinguish itself from similarly-named siblings like action1_delete_automation_action or action1_delete_version.

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 on when to use this vs. alternatives (e.g., delete_version, delete_package, delete_automation_action) or preconditions beyond the permission string. The agent must infer the scenario entirely.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is known. The description adds real value by stating the required permission (manage_vulnerabilities), but it omits the most consequential behavior for an agent: dry_run defaults to true and confirm must be exactly "YES", so a naive call silently does nothing rather than deleting.

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 with the verb and resource front-loaded and no filler. It is efficient, though it is on the thin side for a destructive operation rather than padded.

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

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

An output schema exists and the annotations plus 100% schema coverage carry most of the load, and the permission note is a useful addition. However, for a destructive delete whose execution is gated by confirm and a default-true dry_run, the description should say so — that gap is the main reason it falls short of complete.

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

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

Schema description coverage is 100%, so all five parameters (cve_id, remediation_id, org_id, confirm, dry_run) are documented in the schema itself. The description adds no semantics beyond that, so the baseline 3 applies.

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

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

States a specific verb (deletes) and a specific resource (remediation record of compensating controls), which distinguishes it from action1_update_remediation and action1_delete_package_version_action. It also names the required permission, though 'compensating controls' is slightly ambiguous terminology.

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 on when to use this versus action1_update_remediation or when to first look up the remediation via action1_list_cve_remediations. Nothing warns that this is irreversible or that a preview mode exists, so the agent gets no routing or caution cues from the text.

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