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

Annotations already indicate this is a non-read, non-destructive, non-idempotent operation. The description adds a useful behavioral detail beyond annotations by requiring write permission, which helps an agent anticipate authorization failures.

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

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

Two compact sentences front-load the core action, then add the single most likely input pitfall. There is no unrelated detail or redundancy.

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

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

For a simple two-parameter, no-output-schema tool, the description plus annotations and schema are sufficient for an agent to call it correctly. It could mention what the response looks like, but that is not essential for invocation.

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

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

Schema coverage is 100%, and the schema already documents alert_id and note. The description's LMA-prefix guidance is helpful, but it merely restates what the schema says, so it adds no new semantic value beyond the schema.

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

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

The description opens with a specific verb and resource: "Acknowledge an alert." The singular scope implicitly distinguishes it from sibling bulk_acknowledge_alerts, and the action is unmistakable.

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

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

The description communicates a prerequisite (write permission) and a common mistake about the alert_id format, but it does not explicitly explain when to choose this tool over related siblings such as bulk_acknowledge_alerts or add_alert_note. Usage context is implied 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?

The description adds meaningful behavioral context beyond the annotations: it explicitly says the tool does not acknowledge the alert and requires write permission. Annotations only indicate non-read-only and non-idempotent behavior, so this extra information is valuable.

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

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

The description is a single, front-loaded sentence that conveys the action, the key behavioral distinction, and the permission requirement. Every word earns its place with no redundancy.

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

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

For a simple two-parameter mutation tool, the description covers the essential behavioral context: what it does, what it does not do, and the permission needed. It does not describe return values, but no output schema exists, and the operation is straightforward.

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

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

The schema already provides 100% description coverage for both parameters, including the alert ID prefix flexibility. The tool description adds no additional parameter-level meaning, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Add a note to an alert.' It also distinguishes itself from sibling tools by explicitly stating 'without acknowledging,' which separates it from acknowledge_alert and similar tools.

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

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

The phrase 'without acknowledging' gives clear context for when to use this tool versus an acknowledgment action, while 'requires write permission' sets an important prerequisite. It does not explicitly name sibling alternatives, but the context is clear enough.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds the auth requirement ('requires write permission') and the usage context, which go beyond annotations. It does not discuss failure modes or side effects, but the annotations cover the safety profile sufficiently.

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

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

Two sentences with no redundancy. The core purpose is front-loaded, followed by a usage qualifier. Efficient and directly informative.

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

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

For a simple create operation with no output schema, the description covers the essential purpose and usage context. It lacks an explicit note about return values (e.g., whether the created instance ID is returned), but given the high schema coverage and annotations, this is a minor gap. The description is adequate for an agent to invoke the tool correctly.

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

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

Schema description coverage is 100%, so all parameters already have detailed descriptions, including examples for wild_value. The tool description does not add extra semantic value beyond what the schema provides, so the baseline of 3 applies.

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

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

The description clearly states the verb 'Add' and the resource 'monitored instance to a datasource on a device', making the purpose unambiguous. It also distinguishes from sibling update/delete instance tools by focusing on creation and mentions a specific use case (datasources without Active Discovery).

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

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

It provides a clear condition for use ('Used for datasources without Active Discovery') and an example (ServiceStatus), giving the agent a decision rule. It doesn't explicitly list alternatives or exclusion cases, but the context strongly implies when to choose this tool over related instance operations.

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 explicitly mentions the write-permission requirement, which adds useful access-control context beyond the annotations. The annotations already indicate this is a writing operation (readOnlyHint=false) and non-idempotent, so the description does not need to restate those. It does not disclose side effects or scoping behavior, but the permission note provides some added transparency.

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

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

The description is a single short sentence that communicates both the operation and the key permission constraint. There is no filler, and the core purpose is front-loaded. Every word adds value.

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

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

For a simple creation tool with fully described parameters, the description is minimally adequate, but it lacks important contextual guidance: when to add an ops note versus other note/update tools, what the note is used for, and whether the scoping fields are mutually exclusive or additive. The absence of an output schema also leaves the return behavior unexplained, though that is not strictly required by the rubric.

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 fully documents all four parameters (note, tags, group_ids, device_ids). The description adds no additional meaning about parameter semantics, such as how scoping works or whether tags are controlled vocabulary. The baseline of 3 applies because the schema carries the full weight.

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

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

The description clearly states a specific action and resource: 'Add an ops note.' It is readily distinguishable from sibling update/delete/get ops-note tools by the verb. However, it does not explicitly differentiate itself from conceptually similar tools like add_alert_note, so it stops short of full sibling differentiation.

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 such as add_alert_note or update_ops_note. The only added context is 'requires write permission,' which is a prerequisite rather than a usage guideline. No exclusions, alternatives, or recommended contexts are given.

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

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

The description notes 'requires write permission', which aligns with readOnlyHint=false, but it does not disclose other behavioral aspects such as side effects, return values, or error behavior. The annotations are all false or open-world, so the description carries the burden, yet it focuses on config requirements rather than operational behavior. No contradiction exists.

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

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

The description is a long, dense paragraph without formatting. While each sentence carries essential type-specific information, the structure makes it hard to scan. It is not concise, but given the complexity of config options, the length is justified. A bulleted or sectioned format would improve readability 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?

There is no output schema, yet the description does not mention what the tool returns (e.g., created widget ID or object). It also omits error scenarios, rollback behavior, or limitations. The extensive config details ensure a correct request, but an agent cannot predict the response format, which is a notable gap for successful follow-up actions.

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

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

Schema coverage is 100%, but the description adds substantial value by detailing required config fields for text, bigNumber, cgraph, and deviceSLA widget types. It clarifies expected structures (e.g., GlobMatchToggle objects, 'bigNumberItems' array) and value constraints (e.g., 'displayType' 0/1). This far exceeds the generic 'Widget configuration (type-specific)' in the schema and is crucial for correct invocation.

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

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

The description clearly states the action: 'Add a widget to a dashboard', with a permission note. This verb+resource pair distinguishes it from sibling tools like update_widget, delete_widget, and get_widget, and the purpose is unambiguous.

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

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

The description does not mention when to use this tool versus alternatives (e.g., update_widget for existing widgets). It provides extensive configuration guidance for different widget types, but that is how-to-use parameter advice, not tool-selection guidance. No exclusions or alternative scenarios are mentioned.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds meaningful behavioral context beyond those annotations by disclosing the traversal mechanism, the downstream-impact identification, and the 0-100 scoring range. It does not contradict any annotation, though it omits performance/cost implications of deep traversal on large topologies.

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 totaling about 25 words, with the core purpose front-loaded in the first sentence and the mechanism plus output format in the second. There is zero filler or redundancy, and every clause adds distinguishing 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?

For a moderate-complexity read-only tool, the description covers purpose, mechanism, and score range, while annotations handle the safety profile and the schema has 100% parameter coverage. A minor gap remains: with no output schema present, the description does not fully clarify whether the returned result includes the identified downstream device set in addition to the score, though 'identifies downstream impact' partially implies 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 both device_id and depth are already documented ('Device ID to analyze' and 'Max traversal depth (1-3)'). The description adds only marginal reinforcement by connecting depth to the traversal behavior and device_id to 'device failure', but no new syntax, format, or edge-case meaning is provided beyond the schema. Baseline 3 is appropriate given full schema coverage.

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

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

The description states a specific action ('Analyze the blast radius of a device failure'), the resource/domain ('using topology data'), and the mechanism ('Traverses neighbors to identify downstream impact'). It also specifies the output ('scores overall blast radius (0-100)'), which further disambiguates it from siblings like get_device_neighbors or get_device_connections that merely list relationships.

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

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

The description gives clear contextual signals about when this tool is appropriate: when assessing failure impact, since it explicitly mentions 'device failure', 'downstream impact', and traversal. However, it does not explicitly name alternatives to avoid (e.g., get_device_neighbors for immediate neighbors only) or state when-not-to-use conditions, stopping just short of fully explicit routing guidance.

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

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

Annotations already carry the safety profile (readOnly, openWorld, idempotent, non-destructive), and the description aligns with them while adding behavioral context: it counts specific categories and returns recommendations that convert detection gaps into actionable onboarding steps. This output-behavior detail goes beyond what annotations provide, with no contradiction.

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

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

Two tight sentences with zero waste: the first front-loads what the tool counts, the second explains its output value proposition. Every clause earns its place.

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

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

With no output schema, the description carries the return-value burden and satisfies it by stating a prioritized gap list with onboarding recommendations. It covers scope (portal audit), the counted elements, and output format; the only minor omissions are granularity or behavior details of the gap list, which are not critical for a read-only audit with one optional param.

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 fully documents the single group_id parameter (scope to a device group, omit for portal-wide). The description adds no new parameter-level meaning beyond confirming it is a portal-scoped audit, so the baseline 3 is appropriate.

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

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

The description states a specific verb and resource — a portal audit that counts UPS/PDU onboarding, interface DataSources, SNMP credentials, and NetFlow exporters. It enumerates exactly what is measured and what is returned (a prioritized gap list), making it unambiguous and clearly distinct from the large sibling set, none of which perform this coverage assessment.

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

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

The usage context is implied but not explicit: an audit that produces onboarding recommendations suggests it is meant for assessing monitoring readiness or gap identification, but the description never states when to use it versus related analysis tools like portal_overview, health_check, or diagnose, nor does it name alternatives or exclusions.

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

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

Annotations already mark this as non-read-only, non-destructive, and non-idempotent. The description adds useful behavioral context by stating the max batch size and explicitly requiring write permission, which is valuable beyond the schema and annotations. It does not detail partial-failure behavior, but credit is earned for the disclosed 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?

A single, front-loaded sentence that states the core action first, followed by the batch limit and permission requirement. No filler or redundancy.

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

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

For a two-parameter mutation tool with complete schema coverage and annotations indicating write behavior, the description covers the essential invocation details: what is acted on, batch size, and required permission. It does not explain return values or partial success, but the tool's complexity is low and the existing metadata covers most operational context.

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

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

Schema description coverage is 100%, so the schema already documents alert_ids and note adequately. The description's 'max 100' repeats the schema constraint and does not add new parameter-level meaning.

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

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

Description states a specific action ('Acknowledge') on a specific resource ('multiple alerts') and adds a precise scope constraint ('max 100'). It clearly distinguishes itself from the single-alert sibling acknowledge_alert by emphasizing batch operation.

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

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

The description implies the use case—acknowledging multiple alerts at once—and provides the 100-alert limit and write-permission requirement. However, it does not explicitly state when to prefer this over acknowledge_alert or mention alternatives or exclusions.

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

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

The description adds 'requires write permission' and 'max 100', which is useful context. Annotations already indicate non-read-only and non-destructive, so the bar for added value is lower. However, it does not disclose what happens during bulk creation (e.g., partial failure, all-or-nothing, concurrent behavior), which is relevant for a 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?

A single sentence with no filler. It front-loads the operation ('Create SDT') and then immediately states the key constraint (max 100) and permission requirement. Every word earns its place.

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

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

As a bulk write operation with no output schema, the description should explain expected outcomes, such as whether the entire batch succeeds or partially fails, and what response to expect. It does not mention return values, error behavior, or relationship to related SDT operations. This is a notable gap for an agent attempting to invoke it correctly.

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

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

Schema coverage is 100%: all three parameters have descriptions. The description's phrase 'multiple devices/resources' maps directly to device_ids, but adds no new semantic detail beyond the schema. Baseline 3 is appropriate since the schema carries the descriptive burden.

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 ('Create') and resource ('SDT for multiple devices/resources'), clearly indicating a bulk operation. The term 'resources' adds slight ambiguity, but the parameter name device_ids disambiguates. It does not explicitly distinguish itself from create_sdt, though the 'multiple' scope is implied.

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 explicit when-to-use or alternatives are mentioned. It does not state 'use create_sdt for a single device' or 'use this for batches up to 100'. With sibling tools like create_sdt, bulk_delete_sdt, and list_sdts, the agent receives no routing guidance beyond the tool 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?

Beyond the destructiveHint and readOnlyHint annotations, it adds a concrete permission prerequisite ('requires write permission'), a batch ceiling, and the crucial soft-delete default that tempers what destructiveHint alone would imply. It also lets the agent infer that hard deletion is the opted-in exception via delete_hard.

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

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

Two short sentences front-load the core purpose and constraints, with no filler or repetition. Every clause adds operational 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?

For a two-parameter destructive operation with annotations and full schema coverage, the description covers purpose, permission, limit, and default behavior. It stops just short of explicitly linking soft deletion to recover_device or stating the irreversibility of delete_hard, which would make it fully self-contained.

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% for both parameters, and the description largely restates what the schema already says ('max 100', 'soft delete by default'). It does not add new formats or relationships, so the baseline of 3 applies.

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

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

States a precise action ('Delete'), a bounded resource scope ('multiple devices/resources'), and a single-operation batching guarantee ('max 100'). The bulk scope clearly distinguishes it from the singleton delete_device sibling and from recover_device's opposite 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 clearly signals batch usage ('multiple devices in one operation') and gives a cardinality ceiling, which is the main selection criterion against delete_device. It does not explicitly name alternatives or state when not to use it, but the bulk qualifier makes the intended context unambiguous.

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

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

Annotations already cover destructiveness, read-only status, and idempotency, so the description only needs to add extra behavioral context. It adds the write-permission requirement and confirms batch semantics, which are useful beyond the annotations.

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

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

The description is one compact, front-loaded sentence that conveys the action, scope, limit, and permission requirement with no filler or redundancy.

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

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

For a one-parameter bulk delete tool with rich annotations covering safety and idempotency, this description is sufficient. It provides the core action, a batch limit, and a permission prerequisite, with no output schema requiring return-value explanation.

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

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

The schema already documents sdt_ids as an array of strings with a max of 100, and the description merely repeats the max-100 constraint. No additional format, meaning, or edge-case guidance is provided, so it does not add value beyond the schema.

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

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

The description states a specific verb ('Delete'), a specific resource ('SDTs'), and a clear scope ('multiple at once'). This distinguishes it from the single-item sibling delete_sdt and the device-targeting bulk_delete_devices.

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

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

The phrase 'multiple SDTs at once' clearly signals when this tool should be used, and the 'max 100' cap adds a practical boundary. It does not explicitly name alternatives like delete_sdt for single deletions, so it stops short of a 5.

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

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

Annotations already establish that the tool is read-only, idempotent, and non-destructive, so the description does not need to repeat that. It adds useful behavioral context by specifying the data source (cleared and active alerts) and warning about performance implications of broad queries. This goes meaningfully beyond the structured annotations.

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

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

The description is compact and front-loaded: the core purpose appears in the first sentence, followed by useful operational caveats. Every sentence earns its place, and there is no redundant filler or repetition of schema details.

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

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

For an analytical tool with fully documented optional parameters and read-only annotations, the description provides enough to understand what is computed and how to scope calls efficiently. It does not detail the exact return shape, but it names the key outputs (uptime, MTTR, per-device breakdown), which is sufficient for invocation.

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

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

Schema coverage is 100%, so every parameter is already documented with descriptions and defaults. The description reinforces the hours_back default and the performance value of device_id/group_id filtering, but it does not add substantially new meaning beyond the schema.

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

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

The description uses a specific verb ('Calculate') and identifies the resource ('availability percentage from alert history') plus the derived outputs (uptime metrics, MTTR, per-device breakdown). It is clear and distinct in function, though it does not explicitly contrast itself with neighboring analytics tools like calculate_error_budget or get_alert_statistics.

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 choose this tool over alternatives. The 'Common mistakes' note gives parameter-level tips, such as narrowing scope for performance, but it does not state when this tool is appropriate or when another tool should be used instead.

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

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

Annotations already disclose readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well-covered. The description adds output details (status categories) but no additional behavioral caveats like permission needs or data-scoping behavior, which is acceptable given the annotations.

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

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

Two sentences with zero redundancy. The primary action is front-loaded in the first sentence, and the second sentence adds essential detail in a compact list. The structure is highly efficient.

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

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

The description explains the computation and output categories, but it does not clarify the scope when no filters are provided (e.g., does it calculate for the entire environment?) or how group_id and device_id interact. With no required parameters and no output schema, these gaps leave some ambiguity, though annotations cover the safety aspects.

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 each parameter (group_id, device_id, target_slo, period_days) having a clear description. The tool description does not add extra meaning beyond the schema, such as filter precedence or behavior when no parameters are supplied, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Calculate') and resource ('SLO error budget consumption and projected exhaustion date'), and lists concrete outputs (remaining budget, burn rate, status). This clearly distinguishes it from siblings like calculate_availability, which focuses on raw availability rather than error budget.

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

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

No guidance is given on when to use this tool versus alternatives. The description does not mention sibling tools, prerequisites, or exclusions; usage is only implied by the name and description, which is not enough given the large set of similar analytic tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the tool combines multiple analytical steps (forecasting, classification, seasonality, change points) and returns per-datasource projections. This is useful context but does not go into detailed behavior such as data requirements or how the composite steps interact.

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 dense sentences with zero filler. The first sentence enumerates the tool's analytical capabilities, and the second tells the agent what output to expect. Information is front-loaded and every clause earns its place.

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

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

For a read-only, idempotent analytics tool with 100% schema parameter coverage, the description is mostly sufficient. It states what the tool does and what it returns, but it does not mention how parameters like hours_back or detail_level shape the composite analysis, nor does it advise on when the composite is preferable to individual sibling tools. Still, given annotations and full schema, this is a minor 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% — all six parameters have individual descriptions. The tool description itself doesn't add any parameter-level semantics beyond the schema, so the baseline of 3 applies.

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

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

The description clearly states a specific verb-resource relationship: 'Composite capacity planning' that forecasts breach dates, classifies trends, and detects seasonality/change points. It differentiates itself from sibling tools like forecast_metric or detect_seasonality by explicitly positioning itself as a composite, overarching planning operation.

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

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

The term 'composite' implies this is the all-in-one alternative to individual analysis tools like forecast_metric, classify_trend, detect_seasonality, and detect_change_points. However, it never explicitly says when to choose this tool over those siblings, nor does it state any exclusions or prerequisites. Usage context is implied, not 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 convey read-only, idempotent, and non-destructive behavior, so the description does not need to repeat those. It adds the statistical methods used (linear regression slope, coefficient of variation, autocorrelation), but does not disclose return shape, handling of multiple datapoints, or edge cases.

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

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

The description is two tight sentences with no filler. It front-loads the action and output categories, then gives the relevant methodology in the second sentence.

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

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

The tool is well annotated as read-only and has fully documented parameters, but there is no output schema and the description does not clarify whether the result is a single classification or a per-datapoint mapping. Since datapoints can be omitted to include all, this is a meaningful gap.

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

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

Schema description coverage is 100%, so the parameters are already well documented. The description adds no parameter-specific detail beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description uses a specific verb and resource ('Classify metric trends') and explicitly lists the five output categories, making the tool's purpose clear. It doesn't explicitly differentiate this from sibling analytics tools like detect_change_points or forecast_metric, but the core 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?

There is no guidance on when to use this tool versus alternatives such as get_device_data, detect_seasonality, or detect_change_points. The description mentions methodology but provides no context, exclusions, or selection criteria.

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

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

Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds specificity by enumerating what is cleared (last results, variables, history), which is useful context beyond the annotations. It does not contradict annotations and offers reasonable transparency for a simple 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 a single, front-loaded sentence with no filler. It efficiently communicates the tool's purpose and scope, making it ideal for quick scanning by an agent.

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

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

For a zero-parameter, no-output-schema tool, the description covers everything needed: it states the action and the affected context. There are no missing details about arguments, return values, or side effects that would impede correct invocation.

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

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

The tool has zero parameters, so the schema provides no parameter details. The baseline is 4 for no-parameter tools, and the description does not need to explain parameters. It correctly implies no arguments are required.

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

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

The description states a specific verb ('Clear') and resource ('all session context'), and explicitly lists what is cleared (last results, variables, history). This clearly distinguishes it from siblings like get_session_context, delete_session_variable, and list_session_history, which operate on subsets or retrieve data.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention that delete_session_variable clears a single variable or that get_session_context retrieves context. An agent must infer usage from the name alone, which is not explicit.

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

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

Annotations already indicate non-read-only, non-idempotent, and non-destructive behavior, and the description aligns with those by framing the call as a trigger. It adds the target and on-demand nature, but does not disclose whether collection is asynchronous, how long it takes, or what side effects occur.

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

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

The description is a single sentence with no filler. The action verb is front-loaded and every word contributes to conveying the core operation.

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

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

With no output schema, the description should state what the invocation returns or whether the collection runs asynchronously and requires polling. It also omits any post-condition, leaving an agent unable to verify whether the triggered collection succeeded.

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

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

The input schema fully documents all three parameters, including the clarifying 'Device-DataSource ID for the ConfigSource' description. The tool description adds no parameter-level detail, but the high schema coverage means it does not need to.

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 action verb ('Trigger') and identifies the resource ('on-demand config collection') and target ('device instance'). This distinguishes it from sibling retrieval operations like get_device_config and get_configsource.

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 call this tool versus related siblings such as get_device_config, get_configsource, or create_configsource. No alternatives, prerequisites, or exclusions are mentioned.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description does not contradict these. It adds useful output semantics (deviation percentages and statuses) but does not disclose potential failure behavior, such as what happens if the named baseline does not exist.

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

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

The description is two sentences, front-loaded with the action and followed by the output contract. Every word earns its place, with no repetition of schema details or filler.

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

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

Since there is no output schema, the description correctly provides the essential return information (deviation percentage and status values per datapoint). It omits details like default hours_back and baseline fallback behavior, but these are already covered by the schema, so the combination is sufficient.

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 are already documented in the input schema. The description only summarizes the overall operation and does not add parameter-level meaning beyond what the schema provides.

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

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

The description names a specific verb ('Compare'), a resource ('current metrics against a stored baseline'), and the output contract ('deviation percentage and status ... per datapoint'). This clearly distinguishes it from related siblings like save_baseline or get_metric_anomalies.

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

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

Usage is implied: use this when current metrics need to be checked against a saved baseline. However, it does not explicitly state when not to use it or name alternatives, so an agent is left to infer routing decisions from the tool name and context.

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

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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description only needed to add behavioral context. It does so by disclosing that the tool groups alerts into clusters using device, datasource, and temporal proximity—key behavior an agent cannot infer from annotations alone. It does not mention output shape or algorithmic caveats, but the core analytic behavior is transparent.

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

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

Two sentences with no extraneous content. The action and grouping criteria are front-loaded in the first sentence, and the purpose is stated clearly in the second. It is appropriately sized for the tool's simplicity.

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

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

With no output schema, the description should clarify what a returned 'cluster' looks like, but it does not specify the response structure (e.g., cluster IDs, nested alert lists, ordering). However, the parameters are fully documented and the annotations confirm safety and idempotency, covering much of the operational context. The tool is adequately usable, but the missing output details are a clear 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 coverage is 100%, so the baseline is 3—each parameter (limit, device, group_id, severity, hours_back) already has a complete description with defaults. The description adds a mapping to two concepts (device and temporal proximity) but also mentions 'datasource,' which has no corresponding parameter in the schema; this is a minor ambiguity. Overall the description neither significantly enhances nor undermines the schema's parameter documentation.

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 ('correlate'), a clear resource ('alerts'), and the grouping dimensions (device, datasource, temporal proximity). It clearly distinguishes the tool from raw retrieval siblings like get_alerts and from more specific analysis tools like detect_alert_burst. The second sentence reinforces the purpose by naming the output concept (clusters to identify related issues).

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

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

The description implies when to use it—when you want alerts grouped into related clusters rather than a flat list—but it does not explicitly name alternatives or state when not to use it. Given the large sibling set including get_alerts, get_alert_details, and detect_alert_burst, explicit routing guidance would have been valuable. The intended use case is reasonably inferable but not directly 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 declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful behavioral context: it explains what the tool does with alert and change data and introduces the 'configurable correlation windows' behavior. This goes beyond simply repeating annotation values.

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

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

Two sentences with no filler. The core action and output are front-loaded, followed by the key parameter behavior. Every sentence contributes meaning, and there is zero redundancy.

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

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

The tool has only two optional parameters, both documented, and annotations cover the read-only/idempotent nature. The description explains the analytical purpose sufficiently for an agent to invoke it. A missing output schema is a minor gap, but for this simple two-parameter tool the description is otherwise 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% for both parameters, and the schema already explains their meaning and defaults. The description only mentions 'configurable correlation windows' without adding detail beyond what the schema provides. Hence it meets the baseline but does not exceed it.

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 ('cross-reference') and names the resources ('alert spikes with audit/change logs') and the output ('identifies changes that may have triggered alert increases'). It clearly distinguishes this tool from similar siblings like correlate_alerts and correlate_metrics, which focus on other correlation targets.

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

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

The description implies when to use the tool (when investigating whether changes triggered alert spikes) but does not explicitly state when not to use it or mention alternative tools. Given a large sibling list with several correlation/analysis tools, more explicit guidance would improve clarity, but the purpose is reasonably inferable.

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 non-destructive behavior. The description adds meaningful behavioral detail beyond that: the algorithm (Pearson), the output shape (NxN matrix), the highlight threshold (|r| > 0.7), and the source limit. It does not cover edge-case handling or hours_back behavior, but it provides solid context beyond the annotations.

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

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

Two sentences with no filler: purpose, output, threshold, and limit are all communicated directly. The most important information is front-loaded.

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

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

There is no output schema, so the description appropriately explains the return value as an NxN correlation matrix with highlighted strong correlations. The input schema documents the parameters, and the description covers the key behavioral constraints. Minor gaps remain around exact handling of the hours_back parameter and the semantics of the nested source identifiers.

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 complete for both parameters, so the baseline is 3. The description adds value by stating 'Maximum 10 sources', a constraint not present in the schema, and by framing the sources as 'metric series'. It does not elaborate on nested fields like device_id or instance_id, but those are reasonably clear from the schema.

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

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

The description clearly states the specific verb 'Compute', the resource ('multiple metric series'), and the exact output ('NxN correlation matrix', '|r| > 0.7'). It is easily distinguishable from siblings like correlate_alerts because it focuses specifically on metric-series correlation.

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

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

The description makes the intended use case explicit: correlating multiple metric series, and adds a practical constraint ('Maximum 10 sources'). It does not explicitly name alternatives or exclusion conditions, but the metric-series framing provides clear context versus alert-focused or anomaly-focused siblings.

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

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

Annotations already establish this is a write operation (readOnlyHint=false) and not idempotent. The description adds useful context by explicitly requiring write permission and specifying that stages must reference existing DiagnosticSource or RemediationSource IDs. It does not contradict annotations.

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

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

Two concise sentences with no filler. The core action is front-loaded, and the second sentence clarifies the key requirement about stage references.

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 schema and annotations cover parameters and side-effect profile well. However, with no output schema, the description does not mention what the tool returns (e.g., the new chain ID) or any validation behavior, which leaves a small but relevant gap for an agent.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces that stages are ordered and reference sources by ID, but this information is already present in the schema's property descriptions, so it adds little beyond what is structured.

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

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

The description states a specific action ('Create an action chain') and a specific resource ('action chain'), then clarifies the composition ('from ordered diagnostic/remediation stages'). This clearly distinguishes it from sibling tools like create_diagnosticsource or update_action_chain.

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

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

The description implies the use case: creating a new action chain from existing diagnostic/remediation sources. It also notes a write-permission prerequisite, but it does not explicitly say when to prefer this over update_action_chain or other related 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 indicate this is a write operation (readOnlyHint=false), but the description adds the useful prerequisite of requiring write permission. It does not describe side effects, return values, or failure behavior, but given annotation coverage, the added auth context earns credit without contradiction.

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

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

The description is a single focused sentence that front-loads the action and resource, then adds the key permission requirement. Every part earns its place with no repetition or filler.

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

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

The tool has 10 parameters and no output schema, yet the description is quite brief. The full schema coverage mitigates missing parameter-level detail, but the description omits guidance on alternatives, side effects, or expected behavior after creation, so it is adequate but not fully complete for such a parameter-rich tool.

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

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

Schema description coverage is 100%, so the schema fully documents each parameter. The description adds high-level semantic context by saying the rule binds an action chain to alert conditions, which maps conceptually to action_chain_id and the various matcher fields, but it does not add detail beyond the schema.

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

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

The description states a specific verb ('Create') and resource ('action rule'), and explains the core purpose: binding an action chain to alert conditions. This clearly distinguishes it from sibling operations like update_action_rule, delete_action_rule, set_action_rule_status, and the get_action_rule family.

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 verb 'Create' implies this should be used when a new action rule is needed rather than updating or deleting an existing one, but the description gives no explicit when-to-use or when-not-to-use guidance. It also does not mention alternatives such as set_action_rule_status for enabling/disabling, leaving the routing partly 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 this is not read-only, not idempotent, and not destructive. The description adds the useful operational context that write permission is required, which goes beyond the annotations and helps the agent understand authorization needs. No contradictions exist.

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

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

The description is one compact sentence, front-loading the core operation and system, and includes the write-permission caveat without any filler. Every word earns its place.

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

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

For an 11-parameter mutation tool with no output schema, the description provides only the minimal 'create alert rule' framingable and a permission note. It does not cover behaviors like idempotency or return values, but the fully documented schema and annotations partially compensate, making this a minimum-viable definition.

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 individual parameter meanings are fully documented. The description adds no extra parameter guidance, but the baseline of 3 applies because the schema carries the burden.

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 ('Create'), the resource ('alert rule'), and the system ('LogicMonitor'), clearly distinguishing it from siblings like update_alert_rule and delete_alert_rule. An agent can immediately understand the operation without opening the schema.

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

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

The description implies the tool is for creating a new alert rule, and it adds the prerequisite that write permission is required. However, it does not explicitly state when to use this tool versus alternatives such as update_alert_rule or delete_alert_rule, leaving the routing to inference from the tool 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 convey that this is a write operation (readOnlyHint=false). The description adds the permission requirement, which is useful context beyond the annotations. However, it does not disclose other behaviors like idempotency (idempotentHint=false), what happens on duplicate names, or whether it overwrites. Given annotations cover the safety profile, the description adds minimal but non-zero value.

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 sentence that is immediately clear and front-loaded with the core purpose. No fluff or redundant information. Efficient and well-structured.

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

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

For a simple create operation with only one required parameter, the description is adequate. However, it does not mention the response format or any side effects (e.g., whether the group is immediately usable). Given no output schema, the description could be more informative about what happens on success. It is minimally complete but lacks details that would help an agent anticipate behavior.

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

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

Schema description coverage is 100%, so all parameters are already documented with names and types. The description adds no additional semantics about parameters, such as constraints or relationships. Baseline 3 is appropriate when the schema fully documents 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 clearly states 'Create a collector group' – a specific verb and resource. It distinguishes from sibling get/update/delete_collector_group operations. The purpose is unambiguous.

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

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

No guidance on when to use this tool vs. alternatives. The mention of 'requires write permission' is a prerequisite, not a usage context. It doesn't clarify, for instance, that this is for creating new groups rather than updating existing ones. No when-not-to-use or alternative tool references.

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=false, destructiveHint=false, and idempotentHint=false, so the mutation profile is covered. The description adds the write-permission requirement ('requires write permission') and the overwrite behavior is documented in the schema. The description itself doesn't add much beyond the permission note, but that permission note is genuinely useful context for an agent deciding whether it can call this tool.

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

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

Three sentences with zero waste. The core action and format are front-loaded, the permission requirement is stated, and the sibling routing is given in the final sentence. Every sentence earns its place.

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

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

For a create tool with a nested definition object and no output schema, the description covers the essential context: what format the definition must be in, where to get that format (export_configsource), the permission requirement, and the alternative tool for a different format. The overwrite parameter is documented in the schema. The only minor gap is that the description doesn't describe the return value or what happens on success, but for a create operation this is a relatively minor omission.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds the key semantic detail that 'definition' must be in REST API format and that this matches export_configsource output, which is valuable. However, it doesn't explain the structure of the nested definition object beyond that, so the baseline 3 is appropriate.

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

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

The description states a specific verb ('Create'), a specific resource ('ConfigSource'), and the exact input format ('full definition dict' in 'REST API format'). It also explicitly distinguishes itself from the sibling import_configsource by naming the alternative format (LM Exchange), so an agent can tell them apart without opening either schema.

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

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

The description explicitly says when to use this tool (REST API format, same as export_configsource output) and when not to (for LM Exchange format, use import_configsource). This is a clear when/when-not routing rule that leaves nothing 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 mark this as a non-read-only, non-destructive mutation. The description adds a specific authorization need ('write permission') and the optional template behavior, which are useful beyond the annotations. It does not disclose response behavior or idempotency, but the annotation safety profile covers the main risks.

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

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

The description is a single, compact, front-loaded sentence with no filler and no repetition of schema content. It states the action, the key option, and the permission condition in roughly ten words.

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

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

For a tool with seven parameters and no output schema, the schema carries the parameter detail while the description supplies the decision-relevant context: creation, template support, and authorization. It does not describe the return payload or template-cloning side effects, but those are reasonably inferable from the create action and 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 input schema already documents name, group_id, sharable, template, template_path, and widget_tokens. The description adds no parameter-level meaning beyond noting that a template may be used, so it stays at the coverage-based 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 leads with a specific verb and resource: 'Create a dashboard.' This clearly distinguishes it from sibling tools like update_dashboard, delete_dashboard, and get_dashboards, and the optional template behavior adds precision beyond the tool name.

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 communicates the main precondition ('requires write permission') and makes the basic use case clear: creating a new dashboard. However, it never explicitly says when to prefer this over update_dashboard or how templates are produced, so the usage context is implied rather than fully 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 indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description states it requires write permission, which is a useful addition beyond annotations. However, it doesn't mention side effects like what happens on creation or potential duplicates. With annotations covering part of the safety profile, the description adds some value but not extensive behavioral context.

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

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

The description is a single sentence, brief and front-loaded with the core action. It includes a parenthetical about permissions, which is useful. No wasted words. However, it could arguably be slightly more informative without being verbose.

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

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

Given the tool's simplicity (3 params, no output schema, no nested objects), the description is adequate. It mentions the required permission. The schema covers parameters. The annotations cover safety. It is complete enough for an agent to call correctly. The absence of output schema is not a concern since this is a create operation that likely returns the created object, but that is not specified; still, it's not essential.

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 (name, parent_id, description) are documented in the schema. The description does not add further meaning beyond 'name' being required. Since schema does the heavy lifting, baseline 3 is appropriate. No additional parameter info is needed.

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

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

The description states the action (create) and resource (dashboard group) and the system (LogicMonitor), which is clear. However, it doesn't explicitly distinguish from sibling tools like 'create_dashboard' or 'update_dashboard_group', though the resource type differs. It is clear enough for an agent to understand the primary purpose.

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

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

The description mentions a prerequisite (requires write permission) which gives some usage context, but it does not explicitly state when to use this over alternatives like creating a dashboard or updating a group. It lacks explicit exclusion or alternative guidance. Implied usage is that it's for creating a group, but no comparison to siblings.

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

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

Annotations: readOnlyHint=false, destructiveHint=false, idempotentHint=false. Description adds write permission requirement and notes format compatibility but doesn't elaborate on side effects beyond overwrite parameter. The destructiveHint=false may be contradicted by the overwrite parameter which deletes, but description doesn't explicitly claim no destruction.

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?

Four sentences, each with a distinct purpose: what it does, permission, format, usage scenarios, and special case. Front-loaded with verb+resource.

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 creation tool with one required object param, it's fairly complete. Notes permission, format compatibility, alternative uses, and special type values. Lacks output/return info but no output schema exists.

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

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

Schema covers both parameters (overwrite, definition) at 100%. Description adds meaning by explaining definition must be REST API format and that overwrite deletes existing. The Script datasource type values note adds extra param-related guidance.

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?

Clear verb (Create) + resource (DataSource) + method (REST API from full definition dict). Distinguishes from import_datasource by format (REST API vs LM Exchange). Mentions round-tripping with export_datasource.

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

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

Explicitly says use for round-tripping exports or building from scratch, and directs to import_datasource for LM Exchange format. Also notes Script DataSource datapoints require appropriate type values.

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

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

Annotations already indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds the permission requirement, which is useful context, but does not disclose other behaviors such as return values, idempotency, or duplicate handling. This is adequate given the annotations cover the safety profile.

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

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

The description is a single, concise sentence that front-loads the action and permission requirement. It is appropriately short for a simple create tool, though it omits any usage context that could enhance its value.

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

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

The tool is a straightforward creation operation with a well-covered schema and no output schema. The description covers the essential permission prerequisite but lacks details about what happens on success (e.g., return value) or edge cases like duplicate names. This is minimal but viable.

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% for all six parameters, so the schema already documents each parameter. The description adds no additional parameter-level detail, meeting the baseline for high schema coverage.

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

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

The description states a clear verb-resource pair ('Create a new device/resource') that distinguishes it from sibling create tools like create_device_group. The added 'requires write permission' clarifies access needs, though 'device/resource' is slightly ambiguous given the context.

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

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

No guidance is given on when to use this tool versus alternatives like update_device, delete_device, or bulk creation. There is no mention of prerequisites beyond permission, or scenarios where this tool is preferred.

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=false and destructiveHint=false, so the description does not need to restate mutation. It adds the auth prerequisite 'requires write permission', which is useful context. However, it does not disclose behavioral details such as duplicate-name handling, return values, or hierarchy side effects. The description does not contradict annotations.

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

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

The description is a single sentence with the action and resource front-loaded)Skip any filler. The permission note is appended efficiently. Every word contributes to the message.

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 5 parameters, one required, a nested object, and no output schema, the description is too minimal. It does not explain the structure of custom_properties, the syntax of applies_to, or how parent_id affects hierarchy. An agent would need external knowledge to use the full parameter set correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning about parameters such as applies_to, parent_id, or custom_properties. It relies entirely on the schema's brief field descriptions.

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

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

The description states a specific verb and resource: 'Create a new device/resource group'. This clearly distinguishes it from sibling tools like update_device_group, delete_device_group, and create_collector_group. The permission note does not obscure the core purpose.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention that this is for creating device groups as opposed to updating or deleting them, nor does it compare with other group creation tools. Usage is only implied by the verb and resource 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 declare readOnlyHint=false and idempotentHint=false, covering the mutation profile. The description adds the permission requirement and the REST API format compatibility, but does not disclose side effects of overwrite or return behavior. Since annotations carry the basic safety profile, a 3 is appropriate.

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

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

Two sentences with no wasted words. The first sentence front-loads the action and permission; the second provides a format reference and routes to the alternative. Each sentence earns its place.

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

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

The definition parameter is a complex nested object, and the description compensates by pointing to export_diagnosticsource output as the exact expected format. It does not mention return values, but given no output schema and the annotations covering mutation, this is a minor gap.

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

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

Schema description coverage is 100%, so the schema fully documents both parameters. The description's format note mirrors what the definition schema already states ('Full DiagnosticSource definition in REST API format') and adds only a cross-reference to export_diagnosticsource output. This is marginal value beyond the schema.

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

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

The description states a specific verb ('Create') and resource ('DiagnosticSource'), and explicitly differentiates from import_diagnosticsource by format (REST API vs LM Exchange). It also clarifies the required input shape ('full definition dict'), making it easy for an agent to identify the correct tool among many create_* 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 gives an explicit routing rule: use import_diagnosticsource for LM Exchange format. It also notes the prerequisite of write permission, which helps the agent determine feasibility. This is clear, actionable guidance that resolves the primary ambiguity.

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

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

Annotations already indicate this is a write operation (readOnlyHint=false). The description adds a permission requirement, which is mildly useful, but discloses no side effects, failure modes, or open-world implications beyond that.

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

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

One short, front-loaded sentence with zero redundancy. Every word is informative and the core purpose is immediately visible.

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 7 parameters, including nested destinations with complex structure啵 the description provides no overall guidance on how to construct a valid chain or when this operation is appropriate. The sparse description defers entirely to the schema, which is insufficient for a tool of this complexity without an output 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 each parameter already has descriptive text. The tool description adds no parameter-level meaning, so the baseline score of 3 applies.

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

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

States a specific verb 'create' and resource 'escalation chain', clearly distinguishing it from sibling tools like update_escalation_chain or get_escalation_chains. The action and target 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?

Only mentions a prerequisite ('requires write permission') but gives no guidance on when to use this tool vs alternatives such as update_escalation_chain. No contextual cues, exclusions, or conditions are provided.

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

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

Annotations already mark readOnlyHint=false, and the description adds 'requires write permission' plus the format expectation (same as export_eventsource output). This supplements the safety profile without contradicting annotations. It does not disclose the overwrite deletion behavior, but that is covered by 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?

Two sentences with zero waste. The core action and format are front-loaded, and the alternative is stated concisely. Ideal length for the information provided.

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

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

Covers the essential creation intent, format, and permission. However, it omits any mention of the response or success behavior (e.g., whether the created EventSource is returned), which is left ambiguous given no output schema. For a creation tool, this is a moderate 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 coverage is 100%, so the baseline is 3. The description adds value by clarifying that 'definition' must be in REST API format (matching export_eventsource output), which is a semantic detail not in the schema. This helps the agent format the parameter correctly.

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 (Create), resource (EventSource), and method (via REST API). Clearly distinguishes from import_eventsource by format, preventing confusion. The phrase 'from a full definition dict' further specifies the input requirement.

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

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

Explicitly names the alternative tool (import_eventsource) and the condition that selects it (LM Exchange format). Also mentions the write-permission prerequisite, giving clear when-to-use 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 signal readOnlyHint=false and destructiveHint=false, so the description's 'Create' is consistent. The description adds the write-permission requirement and the extra_fields merge behavior, which are useful context. It doesn't address idempotency or failure modes, but with annotations covering the core safety profile, this is adequate.

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

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

The description is three short sentences, front-loaded with the action and type. The permission note and extra_fields hint are useful, though the extra_fields detail partially duplicates schema content. There is no wasted wording, and the structure is easy to scan.

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

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

For a 24-parameter tool with a rich schema, the description covers the essentials: what is created, required fields, special-field routing, and permission. It doesn't describe return values or lifecycle configuration, but the schema already documents most parameters, and this is a straightforward create operation.

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

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

Schema description coverage is 75%, so the schema carries most parameter documentation. The description reinforces required name/url and summarizes the purpose of extra_fields, but this largely echoes existing schema descriptions for those fields. It adds little new meaning beyond what the schema already provides.

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

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

The description states a specific verb ('Create'), a specific resource ('Custom HTTP Delivery integration'), and the type discriminator ('type=http'). It also names the required fields, which anchors exactly what the tool does. This clearly distinguishes it from siblings like update_http_integration, get_integration, and delete_integration.

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

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

The description gives clear actionable context: this creates a new integration, name and url are required, and extra_fields is the channel for OAuth and lifecycle extras. It also notes the write-permission prerequisite. It doesn't explicitly contrast with update_http_integration or state when not to use it, but the create/update split is clear from the name and the guidance is sufficient.

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

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

Annotations already indicate readOnlyHint=false (a write operation) and destructiveHint=false (not destructive by default). The description adds context by stating it requires write permission and that it creates a LogSource. It doesn't mention the overwrite behavior (which can delete an existing LogSource) but that is disclosed in the schema. The description does not contradict annotations and adds value with the permission requirement and format context.

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

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

The description is two sentences, front-loaded with the core purpose, then immediately gives format guidance and the alternative tool. There is no filler or repetition; every sentence earns its place. The structure is efficient and scannable.

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 create tool with no output schema, the description covers the essential aspects: what it does, the input format, the alternative for a different format, and the permission requirement. It doesn't discuss error handling or idempotency, but those are not typically expected in a description and the annotations cover the idempotency hint. The description is complete enough for an agent to invoke it correctly.

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

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

Schema description coverage is 100% with both parameters having descriptions: definition is 'Full LogSource definition in REST API format' and overwrite is 'If true, delete existing LogSource with same name before creating'. The description adds extra semantic value by clarifying that the definition format is the same as export_logsource output, which helps agents know how to construct the definition. This goes beyond the schema's basic description, so a 4 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 clear verb and resource: 'Create a LogSource via REST API from a full definition dict'. It specifies the exact input format (REST API format) and explicitly contrasts with import_logsource, which accepts LM Exchange format. This clearly distinguishes it from siblings like update_logsource or delete_logsource.

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

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

The description provides explicit usage guidance: it states that this tool accepts REST API format (the same as export_logsource output) and directs the agent to use import_logsource for LM Exchange format. It also notes the write permission requirement, which is a prerequisite. This is a clear when-to-use and when-not-to-use with an explicit alternative.

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

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

Annotations already indicate write operation (readOnlyHint false) and non-idempotent (idempotentHint false). The description adds value by specifying permission requirements and the accepted format, and notes that overwrite can delete an existing PropertySource (implied by the overwrite parameter in schema). No contradiction with annotations.

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

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

Three concise sentences, front-loaded with the core purpose, followed by usage guidance and alternative. No fluff or redundancy.

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

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

Given the schema fully documents parameters and annotations cover basic flags, the description is sufficient for an agent to decide when to use and what format to provide. It lacks explicit mention of return values or error behavior, but these are not critical for a create operation without an output 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 covers both parameters (definition and overwrite) with descriptions, so baseline is 3. The description adds a hint about the definition format ('full definition dict' in REST API format), which slightly enhances understanding but is not essential given 100% schema coverage.

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

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

Clear verb 'Create' with resource 'PropertySource' and explicit format specification (REST API format). It distinguishes from import_propertysource, which uses LM Exchange format, and references export_propertysource output, making the purpose unambiguous.

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

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

Explicitly states when to use (round-tripping exports or building from scratch) and provides an alternative (import_propertysource for LM Exchange). Also notes the required write permission, guiding the agent on prerequisites.

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

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

Annotations already signal non-read-only and non-idempotent behavior, so the description's added value is the explicit authorization requirement, 'requires write permission'. This is a useful behavioral trait beyond the structured annotations, though the description does not cover potential duplicate-name failures or response 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?

A single front-loaded sentence contains the action and a key prerequisite without filler. Every word contributes meaning, and the tool's scope is immediately clear.

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

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

For a simple, three-parameter create operation with complete schema coverage and safety annotations, the description plus schema provide enough to call the tool correctly. It does not describe return values, and no output schema exists, but none are essential for invocation.

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

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

Schema coverage is 100%, so each parameter is already documented in the input schema. The description itself adds no parameter-level meaning beyond the operation, matching the baseline for full schema coverage.

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

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

The description uses the imperative 'Create' with a specific resource, 'recipient group', and is clearly distinguished from sibling update/delete/get tools by the create verb. It states the operation concisely and unambiguously.

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 conveys the basic context for using the tool (creating a new recipient group) and adds a permission prerequisite, 'requires write permission', but it never explicitly contrasts with alternatives such as update_recipient_group or delete_recipient_group. Usage guidance is therefore implied rather than explicit.

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

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

Annotations already establish this as a non-read-only, non-idempotent operation, so the description only needs to add context beyond that. It adds a permission requirement and clarifies that the input format matches export_remediationsource output. The overwrite behavior is left to the schema, which is acceptable given 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?

Three short sentences with no filler. The core purpose is front-loaded, and every sentence adds useful context: creation, format compatibility, and the missing import endpoint.

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 create operation with a nested definition object, the description provides enough context to invoke it correctly: permission, input format, and an export reference for constructing the definition. It does not mention return values, but with no output schema and a straightforward create action, this is a minor 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 coverage is 100%, so the baseline is 3, but the description adds value by telling agents that the definition can be sourced directly from export_remediationsource output. This is a practical semantic pointer beyond the schema's 'REST API format' label.

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

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

The description opens with a specific verb and resource: 'Create a RemediationSource via REST API from a full definition dict.' It clearly identifies the operation and the input style, and it differentiates itself from related tools by noting the export-format compatibility and the absence of an LM Exchange import endpoint.

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

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

It states the write-permission prerequisite and explicitly says RemediationSources have no LM Exchange import endpoint, which routes agents away from an import alternative. It does not explicitly contrast with update_remediationsource, but 'create' vs. 'update' is self-evident 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 indicate this is not read-only and is not idempotent; the description adds a write-permission requirement, which is useful context. It does not disclose side effects, validation behavior, or whether scheduling parameters affect creation, but this is acceptable given the annotation coverage.

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

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

The description is one concise sentence with no redundant words. The core purpose is front-loaded, and the permission note is appended without bloating the definition.

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

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

This is a moderately complex create operation with seven parameters, including scheduling fields, and no output schema. The schema covers parameter meanings, but the description does not clarify expected return values, report_type value constraints, or how schedule_cron interacts with on-demand generation, leaving minor gaps.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters. The description adds no additional parameter-level meaning beyond what the schema provides, matching 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 states a specific action and resource: 'Create a new report'. This clearly separates it from sibling tools like get_reports, run_report, update_report_schedule, and delete_report by the creation verb and target resource.

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

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

No guidance is given on when to use this tool versus alternatives such as run_report or update_report_schedule. The permission note is useful but does not help an agent choose among related report operations.

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

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

Annotations already indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds behavioral value beyond these hints by warning that duration_minutes is minutes not hours/seconds, that specific SDT types require specific IDs, and that cloud resources may not support DeviceSDT. No contradiction with annotations.

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

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

The description is compact and front-loaded with the purpose, followed by a dense, high-value 'Common mistakes' section. Every sentence adds useful information, with no filler or redundancy.

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

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

The tool supports 13 sdt_type enum values, but the description only covers three of them (DeviceSDT, DeviceGroupSDT, DeviceDataSourceSDT) plus one cloud caveat. It does not explain how to specify other types such as ServiceSDT, WebsiteSDT, or CollectorSDT, and it omits scheduling semantics like start time. With no output schema, these gaps make the description incomplete for the full range of supported invocations.

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 meaning beyond the schema by clarifying cross-parameter dependencies: DeviceSDT needs device_id, DeviceGroupSDT needs device_group_id, and DeviceDataSourceSDT needs device_id plus datasource_id. It also clarifies the units for duration_minutes, which the schema does not emphasize.

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 scheduled downtime'. This clearly identifies the tool's role and distinguishes it from siblings like update_sdt, delete_sdt, and list_sdts. The 'requires write permission' note reinforces the operation type.

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

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

The description provides a useful precondition ('requires write permission') and internal routing guidance, such as using DeviceGroupSDT for cloud resources. However, it does not explicitly say when to choose create_sdt over sibling tools like bulk_create_device_sdt or update_sdt, so the when-to-use guidance is only partially complete.

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

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

Annotations already indicate non-read-only behavior; the description adds a meaningful authorization requirement ('requires write permission') and a format constraint. It does not describe return values or failure behavior when overwrite is false, but overwrite semantics are covered by 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?

Two sentences, no filler. The core purpose and format are front-loaded, and the alternative tool is mentioned immediately after the primary use case.

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

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

The description plus schema covers what is needed to invoke the tool: format, permission, overwrite behavior, and routing to the import alternative. It lacks return/error details, but there is no output schema and the nested definition shape may be documented elsewhere.

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 applies. The description adds some context by calling definition a 'full definition dict' and noting the REST API format, but it does not explain the nested definition structure or per-parameter behavior beyond the schema.

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

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

States a specific verb ('Create'), resource ('TopologySource'), input form ('full definition dict'), and format ('REST API format'). Explicitly distinguishes this from import_topologysource, so an agent can select it unambiguously.

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 an explicit when-to-use signal: creating a TopologySource in REST API format. Also gives an explicit alternative with the condition for using it: 'For LM Exchange format, use import_topologysource.'

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

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

The annotations already declare readOnlyHint=false, so agents know this is a state-changing call. The description adds one useful detail beyond the annotations: the write-permission requirement. However, it discloses nothing about side effects, such as whether an invitation email is sent, whether username must be unique, or what happens on duplicate creation.

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

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

The description is a single front-loaded sentence with zero wasted words: the core action leads, and the permission requirement is tucked into a short parenthetical. It reads as concise rather than bloated, though it is so minimal it borders on under-specification, which is better penalized under contextual completeness.

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 mutation tool with 11 parameters and no output schema, this description is thin. It covers the permission prerequisite but omits context an agent needs when calling it: what a successful creation returns, whether api_only changes the password requirement, and whether roles must reference existing role IDs. The annotations cover the safety profile, but the description carries too little of the behavioral load.

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 of 3 applies - all 11 parameters, including defaults for api_only and two_fa_enabled, are already documented in the schema. The description adds no parameter-level insight beyond the schema, such as how roles map to get_roles or how password interacts with api_only.

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 user in LogicMonitor'. The action is unambiguous and the verb inherently distinguishes it from sibling tools like get_user, update_user, and delete_user, though it never explicitly calls those alternatives out.

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

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

Usage is implied: use this when you need a new user in LogicMonitor. The write-permission parenthetical hints at a prerequisite for calling it, but the description does not state when this is preferred over alternatives like update_user, nor any exclusions or preconditions such as roles needing to exist first.

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

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

Annotations already indicate this is not read-only and not idempotent, and the description adds the useful prerequisite that write permission is required. It does not disclose side effects or response behavior, but with annotations covering the basic safety profile, this is adequate though not rich.

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

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

The entire description is one short sentence with no filler. It front-loads the operation type and includes only the essential permission note. Every word contributes value.

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

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

The description is minimally viable: it names the operation, platform, and permission requirement, while the schema covers parameter details. It does not mention expected response, relationship to website groups, or any post-create behavior, but for a simple create call with a fully documented schema this is acceptable.

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

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

Schema description coverage is 100%, so the input schema already documents all 7 parameters including required fields and defaults. The description adds no parameter-level detail, which is acceptable because the schema carries the full semantic burden.

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

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

The description uses a specific verb and resource ('Create a website check') and identifies the platform (LogicMonitor). It distinguishes this from the sibling create_website_group by specifying 'website check' rather than group, so there is no ambiguity about what is being created.

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

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

The description clearly establishes when the tool applies: use it to create a website check in LogicMonitor. It does not explicitly name alternatives or exclusions, but the wording is precise enough that an agent can tell it apart from related tools like create_website_group or update_website.

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

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

Annotations already indicate a write operation (readOnlyHint=false), so the description's added value is limited to the explicit permission requirement. It does not disclose duplicate handling, response behavior, or side effects beyond creation, but this is acceptable given the simple create operation and existing annotation coverage.

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

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

The description is a single, front-loaded sentence that states the core action and the key prerequisite. There is no redundancy or filler.

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

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

For a low-complexity create tool with a fully documented schema and annotations covering side-effect profile, the description is sufficiently complete. The absence of an output schema is not a gap because none is provided, and the permission requirement is a useful addition.

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 (name, parent_id, description) are already documented in the schema. The description adds no additional parameter-level 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 specific verb ('Create'), a precise resource ('website group'), and the system ('LogicMonitor'). This clearly distinguishes it from sibling tools like create_website, get_website_groups, and delete_website_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 description implicitly communicates when to use the tool (when creating a website group) but provides no explicit guidance on alternatives or exclusions. The permission note ('requires write permission') is a prerequisite but not a usage boundary.

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?