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

Annotations already convey that this is a write operation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds the contextual detail that creation happens within a tenant, but it does not disclose side effects, uniqueness constraints, or what happens on success. It adds some value but not rich 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 one short sentence with no wasted words. It is front-loaded with the action and resource. It is concise, though it achieves this at the cost of richer context.

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

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

Even though an output schema exists and annotations are present, the description alone leaves out important context like parameter semantics and any usage constraints. For a create operation, an agent would benefit from knowing required fields' roles and any side effects. The description is too thin to be considered 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 0%, so the description must compensate for parameter documentation. It only vaguely implies tenant_id's role by saying 'in a tenant' and provides no meaning for name, tags, or description beyond their names. The parameter names are somewhat self-explanatory, but the description does not provide the needed clarification.

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

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

The description uses a specific verb ('Create') with a specific resource ('application') and a scope ('in a tenant'). It clearly distinguishes this tool from siblings like application_update, application_delete, and application_get, leaving no ambiguity about what operation it performs.

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 obvious use case of creating a new application, but it does not explicitly state when to prefer this tool over alternatives or mention exclusions such as 'use application_update to modify an existing application.' There is no when-not-to-use guidance.

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

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

Annotations already mark the tool as destructive, and the description adds important context by stating that all of the application's devices are also deleted. This goes beyond the annotation by specifying what exactly is affected, which is valuable for an agent to warn users or confirm scope.

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, front-loaded with the action and resource, and including the crucial cascade detail. Every word earns its place.

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

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

For a simple delete operation with one parameter, the description covers the key information: what is deleted and the cascade. An output schema exists so return values need not be described, and the destructive annotation covers permanence. Nothing critical is missing.

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

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

With 0% schema description coverage, the description does not compensate by explaining the 'application_id' parameter. However, the parameter name is self-explanatory and the description implies the need to identify an application. The single parameter is simple enough that the lack of explicit documentation is a minor gap.

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 ('Delete') and resource ('application'), and further specifies the cascading effect on associated devices. This clearly distinguishes it from other application tools like application_get or application_update.

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

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

The description implies usage when an application and its devices need to be removed, but does not explicitly discuss when to choose this tool over alternatives or mention any exclusions. The intent is inferred from the verb and resource rather than spelled out.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds no behavioral context beyond that, such as behavior on invalid IDs, response format, or any side effects. It does not contradict the annotations.

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

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

The description is a single, focused sentence with no wasted words. For a simple one-parameter get operation, it is appropriately concise and easy to parse.

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

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

With annotations covering safety and an output schema presumably describing return values, the description is mostly sufficient for such a simple tool. However, it lacks any mention of usage context or how to distinguish from application_list, making it minimally adequate rather than fully complete.

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

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

Schema description coverage is 0%, so the description should compensate for the undocumented parameter, but it does not mention application_id or how to use it. The parameter name is self-explanatory, which prevents a score of 1, but the description adds no 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 clearly states the action ('Get') and the resource ('an application'), making it evident this is a read operation for a single application. However, it does not explicitly differentiate from application_list; the singular 'an application' and the schema's application_id provide enough implicit distinction.

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

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

The description provides no guidance on when to use this tool versus alternatives like application_list. While the name and singular form imply fetching one application by ID, there is no explicit usage context or mention of sibling tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description is consistent and adds tenant scoping as the key contextual trait. However, it does not disclose pagination behavior, search semantics, or any other operational traits beyond what annotations and schema suggest.

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, direct sentence with no filler or redundancy. It is front-loaded with the verb and resource and earns its place without unnecessary detail.

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

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

The output schema exists and annotations cover the safety profile, so the description does not need to explain return values or read-only behavior. However, with four parameters and no schema descriptions, the missing explanation of pagination and search parameters leaves the description merely adequate rather than 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 0%, so the description needed to compensate for all four parameters. It only clarifies tenant_id via 'of a tenant' and leaves limit, offset, and search entirely unexplained. This is partial but insufficient semantic 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?

The description clearly states the action ('List'), the resource ('applications'), and the scope ('of a tenant'). This distinguishes it from sibling tools like application_get (single application) and application_list_device_tags (different sub-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?

The description implies use when an agent needs all applications belonging to a tenant, but it does not explicitly say when to use this tool over application_get or other list tools. No exclusions or alternative routing are provided.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the 'distinct' deduplication behavior, which is useful, but it does not disclose other behaviors such as ordering, pagination, or invalid-input handling. The low bar for annotations is met, but no extra depth is provided.

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

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

The description is a single, well-structured sentence with no wasted words. The verb and core scoping information are front-loaded, making it immediately parseable 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 simple read-only tool with one self-evident parameter and an output schema, the description is largely complete. The only minor gap is the lack of explicit usage guidance, but given the tool's simplicity and the absence of closely overlapping siblings, this does not significantly impede 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 0%, and the description does not add details about application_id format or semantics beyond the obvious 'used inside an application' hint. However, the single parameter name is self-explanatory, and the minimal context provided is sufficient 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 uses a specific verb ('List') and identifies the resource ('distinct device tag keys and values used inside an application'), making the tool's function immediately clear. It is clearly distinguishable from siblings like device_list or application_list because it targets tags, not devices or applications.

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

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

The phrase 'used inside an application' implies the tool applies when working with an application's device tags, but there is no explicit guidance on when to use this tool versus alternatives. No exclusions or alternative tool references are provided, leaving the usage context largely implied.

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

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

Annotations only say readOnlyHint=false and destructiveHint=false; the description adds the crucial partial-update behavior and warns that tags are replaced wholesale rather than merged. This is meaningful behavioral context not available in the schema.

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

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

Two short sentences with the core update semantics first and the tag gotcha second. Zero 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 update tool with an output schema, the description covers the main ambiguity (partial vs full update, tag merge vs replace). It could mention how null values behave, but 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?

The description adds real meaning for `tags` (whole-map replacement) and implies omitted fields are untouched. However, schema description coverage is 0% and the description does not address the `null` semantics for clearing fields or detail `name`/`description` beyond their obvious names.

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

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

The description names the action (Update), the resource (application), and the precise PATCH-like scope ('only the given fields'), which clearly separates it from application_create/delete/get. The behavior is immediately recognizable even 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?

It clearly defines the update context: modifying selected fields of an existing application, not full replacement. It does not explicitly name sibling tools or state when not to use it, so it stops short of full exclusion 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 mark the operation as read-only and non-destructive. The description adds value beyond annotations by explaining that terminal-error sessions are included and that stream_state may use a 'stopped:' prefix, giving the agent useful expectation about result contents.

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

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

The description is a single sentence that front-loads the core purpose and appends only the one important behavioral nuance. There is no filler, repetition, or unnecessary detail.

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

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

For a zero-parameter list operation with an output schema and read-only annotations, the key semantics are covered: what is listed and the notable inclusion rule. Ordering or pagination details are not mentioned, but those are likely represented in the output schema and are secondary for such a simple tool.

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

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

The input schema has no parameters and the description correctly adds none. With zero parameters, the baseline of 4 applies because there is no parameter meaning that needs clarification.

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

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

The description clearly states a specific verb and resource ('List capture sessions') and adds a distinctive inclusion detail (sessions stopped by a terminal error). This makes it easy to distinguish from sibling capture_start, capture_read, and capture_stop operations.

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 frames this as the listing operation for capture sessions, which is the natural use case. It does not explicitly state when not to use it or name an alternative list tool, but there is no competing capture_get/list sibling, so 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?

Adds significant non-obvious behavior beyond the readOnlyHint annotation: items carry a `live` flag whose false/true meanings are explained (replay versus live session data). It also exposes the need to monitor stream_state, which is exactly the kind of runtime behavior an agent needs to know to use the tool correctly.

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, dense sentences with no filler. The core action is front-loaded, then operational instructions, then the crucial live/replay semantics. 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?

Covers the essential stateful behavior: sequencing, reconnection checking, and replay semantics. The presence of an output schema likely provides where last_seq and stream_state appear, so the description does not need to repeat that. Slight gap: limit is never mentioned, but its meaning is fairly self-evident.

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 0%, so the description must compensate. It fully explains since_seq semantics ('seq > since_seq', pass last_seq back), which is the least obvious parameter. However, session_id and limit are left to inference from their names/context and are not explicitly described.

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

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

States a specific verb and resource: 'Read captured items with seq > since_seq.' This clearly identifies what the tool does and distinguishes it from capture lifecycle tools like capture_start/capture_stop and capture_list. The inclusion of the sequencing detail makes 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?

Provides explicit operational guidance: remember last_seq and pass it back next time, and check stream_state for reconnects. This tells the agent how to paginate and handle reconnections. It does not explicitly contrast with alternatives, but the stream/read 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?

The description adds meaningful behavior beyond annotations: the capture runs in the background, returns a session_id for follow-up reads, and sessions idle for 30 minutes are dropped. This is important lifecycle information that the annotations alone do not provide. No contradiction with readOnlyHint=false or destructiveHint=false.

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

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

The description is two sentences with no filler. The action is front-loaded, the session_id return is mentioned immediately, and the 30-minute timeout is a compact but useful lifecycle note. 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?

The description adequately covers invocation, return value, how to consume the capture, and session expiration. Since an output schema exists, the return shape is already specified. The only notable gap is the exact format of the required 'target' parameter, but given the simple two-parameter schema and sibling context, this is a 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?

With 0% schema description coverage, the description carries the parameter-semantics burden. It conveys that 'target' identifies a device or gateway and that 'kind' distinguishes device events, device frames, and gateway frames. It stops short of specifying the exact target identifier format, but it provides enough semantic grounding beyond the bare 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 action: 'Start a background capture' of a device's events/frames or a gateway's frames. It distinguishes itself from the sibling capture_read/capture_stop/capture_list tools by explaining this is the initiating operation and explicitly points to capture_read for incremental consumption.

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 practical guidance: start a capture, receive a session_id, then 'read incrementally with capture_read.' It also notes the 30-minute idle timeout. It does not explicitly discuss when to use capture_stop or capture_list, but the core read-vs-start distinction is clear.

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

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

Annotation Contradiction: The description says the tool will 'discard its buffer,' which is a destructive loss of captured data, but annotations declare destructiveHint=false. This directly contradicts the annotation and obscures the tool's real effect.

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 concise sentence with no wasted words. The action is front-loaded and the side effect is stated directly.

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 simple and has an output schema, so return value explanation is unnecessary. However, the contradiction about destructiveness leaves the behavioral contract unclear, and there is no mention of lifecycle context or what happens with an invalid/expired session.

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 0%, and the description does not explain where session_id comes from or what format/state it should be in. The phrase 'capture session' provides some semantic link, but it is not enough to compensate for the missing schema 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 uses a specific verb ('Stop') and resource ('capture session'), and adds a clarifying side effect ('discard its buffer'). This makes it clearly distinct from siblings like capture_start, capture_read, and capture_list.

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

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

The intended use case is implied: stop a capture session when you no longer need it. However, the description does not explicitly say when to use this tool versus alternatives, nor does it note prerequisites such as reading the buffer before stopping if the data is needed.

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 destructive, and the description adds valuable behavior beyond that: activating via ABP or resetting an OTAA session, plus the network-key defaulting rule. No contradiction with the destructiveHint annotation.

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

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

Two tight sentences convey the core operation, the alternative use case, and a protocol-specific key rule. 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 destructive 9-parameter activation tool with 0% schema description coverage, the description is too thin. It lacks meaning for most required parameters, does not explain format expectations, and gives no guidance on prerequisites or side effects beyond the key default.

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 0%, so the description carries the burden for explaining parameters. It only clarifies the nwk_s_enc_key defaulting relationship; required parameters like dev_eui, dev_addr, and app_s_key, plus counter semantics, are left unexplained.

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

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

The description uses a specific verb and resource: 'ABP-activate a device (or reset an OTAA session)'. This clearly identifies the operation and distinguishes it from siblings like device_deactivate or device_set_keys.

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

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

The description gives clear context for when the tool applies: ABP activation or OTAA session reset. It also provides conditional guidance for LoRaWAN 1.0.x key handling, though it does not explicitly 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 indicate this is a mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds useful context that key/session provisioning is not part of creation and must happen afterward, but it does not disclose other behaviors like validation, defaults, or failure conditions.

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

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

Two short sentences with no filler. The primary action is front-loaded, and the follow-up routing sentence earns its place by preventing misuse.

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 10 parameters and zero schema descriptions, the description is too thin. It does not explain how to obtain application_id or device_profile_id, what values are expected for dev_eui, or the significance of optional fields, leaving important context to inference.

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 0%, and the description names none of the 10 parameters. It does not explain required identifiers, the meaning of skip_fcnt_check, or how tags/variables are used, so the agent receives no parameter-level guidance beyond raw property names.

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

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

The description opens with 'Create a device,' stating a specific verb and resource. It further distinguishes this creation action from downstream provisioning by directing the agent to device_set_keys and device_activate, so it is not confused with those sibling tools.

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

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

The description gives clear sequential guidance: use this tool to create the device, then use device_set_keys for OTAA or device_activate for ABP. It does not explicitly state exclusions such as 'use device_update for modifications,' but the create-vs-configure context is clear enough for selection.

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

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

Annotations already indicate destructiveHint=true, and the description adds specific behavioral context: the session is dropped and the device must re-join to communicate again. This goes beyond the annotation by explaining the operational consequence.

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 states the action and its key consequence efficiently.

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 single-parameter destructive operation with an output schema and destructive annotation, the description covers the essential behavior and consequence. It is slightly incomplete because it omits explicit usage guidance, but the operation is simple enough that the information provided is largely 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 0% for the dev_eui parameter, and the description does not mention the parameter or explain how to identify the target device. While 'dev_eui' is a self-explanatory parameter name, the description provides no compensatory semantic 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?

The description uses a specific verb and resource: 'Drop the device session,' and clearly states the consequence that an OTAA device must re-join before communicating. This distinguishes it from siblings like device_delete and device_activate without ambiguity.

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

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

The description implies the usage scenario: deactivating a device to force a re-join. However, it does not explicitly state when to prefer this over alternatives such as device_delete or device_activate, and it does not address how non-OTAA devices are affected.

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

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

Annotations already flag destructiveHint=true, and the description adds the concrete scope that all stored ChirpStack data associated with the device is deleted. This goes beyond the generic destructive flag by clarifying the blast radius, though it doesn't mention reversibility or auth requirements.

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, efficiently worded sentence with no filler. It front-loads the action and scope.

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 destructive tool with a clear annotation and an output schema, the description conveys the essential behavior. It could mention irreversibility or prerequisites, but the combination of annotations and description is sufficient for an agent to understand what will happen.

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 0%, and the description does not explain the dev_eui parameter or how to identify the target device. The parameter name is self-explanatory, but the description itself adds no meaning beyond the bare schema field.

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 specific verb 'Delete' and resource 'device', and adds the clarifying scope 'everything ChirpStack stores about it,' which distinguishes it from sibling tools like device_deactivate that imply a less destructive operation. This gives an agent a precise understanding of what the tool does.

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 alternatives or when-to-use guidance is provided; the description only implies that this is for complete device removal. The agent must rely on sibling names and context to distinguish it from device_deactivate or device_flush_dev_nonces. This leaves usage decisions 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?

Beyond the annotations, the description discloses meaningful behavior: the payload may be supplied in three formats, the profile codec is involved, and Class A devices receive the downlink after their next uplink. This adds real behavioral context beyond the minimal readOnlyHint and destructiveHint annotations.

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

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

The description is two tight sentences with no filler. It front-loads the core action and then provides the essential encoding and timing 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?

The description covers the core enqueue behavior and the output schema exists for return values, but it lacks guidance on queue interaction, error conditions, or how to choose among the payload formats with respect to device capabilities. It is adequate but not fully complete for a 7-parameter tool with no in-schema descriptions.

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 0%, so the description must compensate. It explains data_hex, data_base64, and object as payload alternatives, but it leaves dev_eui, f_port, confirmed, and expires_in_s to bare names and types, which is only partially sufficient 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 uses a specific verb and resource: 'Queue a downlink.' This clearly identifies the action and distinguishes it from sibling queue operations like device_queue_get and device_queue_flush, even without naming them.

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

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

The description gives practical payload guidance and explains Class A receive timing, but it does not explicitly state when to prefer this tool over device_queue_get or device_queue_flush. Usage context is implied rather than explicitly contrasted with alternatives.

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

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

The description goes beyond the destructiveHint annotation by specifying exactly what gets destroyed ('used DevNonces') and the resulting behavioral effect. It does not discuss irreversibility or broader side effects, but the annotation already signals destruction and the description adds meaningful 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, front-loaded sentence with no wasted words. It states the action, the resource, and the motivating scenario efficiently.

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

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

This is a simple single-parameter tool with an output schema and destructive annotation already supplied. The description adequately covers the operation's purpose and triggering condition, so an agent has enough context 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 0%, and the description does not explain the dev_eui parameter at all. An agent can infer that dev_eui identifies the target device from the property name and tool name, but the description itself contributes no additional parameter 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?

The description uses a specific verb ('Forget') and resource ('used DevNonces') and explains the intended effect on device join-requests. This clearly distinguishes it from sibling tools like device_queue_flush, which operates on a different queue.

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

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

The description provides a clear usage scenario: use when a device's join-requests are rejected as replays. It does not explicitly name alternatives or exclusions, but the context is specific enough for an agent to know when this tool is appropriate.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds meaningful behavioral context beyond annotations: it discloses that the tool returns current activation/session and that include_keys reveals not only OTAA root keys but also session keys in activation.

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 behavior and then add the conditional key disclosure. Every clause contributes useful information with no filler, redundancy, or unnecessary detail.

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

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

For a simple read-only getter with two parameters, an output schema, and read-only annotations, the description is complete. It states what the tool returns, how the include_keys flag alters the response, and the scope as a single device lookup. No prerequisites or error-case elaboration are necessary here.

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 0%, so the description must carry parameter meaning. It explains include_keys precisely and notes its side effect of revealing session keys. However, dev_eui is left to the parameter name and type; the description does not clarify the expected value format or identifier semantics.

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

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

The description clearly identifies the specific operation ('Get a device') and the resources involved: the device, its current activation/session, and optional OTAA root keys and session keys. This differentiates it from device_list (plural fetch) and mutation tools like device_update or device_delete.

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

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

The description implies usage when a single device's current session or key material is needed, and the 'if include_keys' clause provides conditional guidance for requesting keys. However, it does not explicitly state when to prefer this tool over device_list or other getters, nor does it mention any exclusions or alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds application scoping and the optional search filter, but it does not mention pagination behavior, result ordering, or whether all device fields are returned. This is acceptable given the annotations but not rich.

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

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

The description is a single focused sentence with no filler. The verb and resource are front-loaded, and the optional filter is stated concisely. It earns its place without unnecessary detail.

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

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

For a simple read-only list operation with an output schema and fairly self-explanatory parameters, this description is mostly complete. It identifies the required application scope and the optional search filter. Explicit pagination guidance for limit/offset is missing, but the parameter defaults and names make the behavior reasonably clear.

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

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

Schema description coverage is 0%, so the description must carry the meaning for parameters. It only explains 'search' as a filter; application_id is inferable from the phrase 'in an application', while limit and offset are not described at all. The description does not fully compensate for the lack of schema descriptions.

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

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

The description uses a specific verb ('List'), a clear resource ('devices'), and an explicit scope ('in an application'). The optional search filter is also stated. This clearly separates it from device_get, device_create, and unrelated list tools like profile_list or gateway_list.

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

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

No guidance is given about when to use this tool versus alternatives such as device_recent_events, device_queue_get, or other listing endpoints. The application scope is implied, but there are no exclusions, conditions, or references to sibling 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 mark this as read-only and non-destructive. The description adds useful behavioral context beyond that: it defaults to the last 24 hours, and the metric set is codec-defined, meaning output can vary by device codec. No contradiction with annotations.

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

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

Two short sentences with no filler. The core content is front-loaded, and the default time window is stated efficiently.

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 four parameters, an output schema, and a close sibling in gateway_metrics, the description is too sparse. It omits aggregation granularity, start/end semantics, and any guidance for choosing between device_metrics and gateway_metrics. The output schema helps, but the input contract remains under-specified.

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 0%, so the description must compensate for undocumented parameters. It clarifies the default time window, which maps to start/end, but it does not explain what dev_eui identifies, how aggregation affects results, or the expected start/end format. Three of four parameters remain underexplained.

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 identifies the resource as device metrics and lists concrete content: RSSI, SNR, packets per frequency/DR, errors, and codec-defined metrics. It is clear this is about device-level link quality, though it lacks an explicit retrieval verb and does not directly contrast with gateway_metrics.

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 by the name and content: an agent would use this when it needs device-level link-quality and codec-defined metrics. However, the description does not explicitly say when to prefer this over gateway_metrics or other sibling tools, and it provides no exclusions.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is covered. The description adds the useful severity detail that ALL queued downlinks are discarded rather than a subset, which goes slightly beyond the annotation, but it does not add context on irreversibility, prerequisites, or effects on in-flight messages.

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 useful content fits in one sentence with a front-loaded verb and zero wasted words. It is appropriately minimal for a tool this simple.

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 simple (one parameter) and the output schema exists, so return values need no explanation. However, the description still leaves gaps: no confirmation of the operand semantics, no caution about the destructive effect beyond the annotation, and no context about when clearing the whole queue is appropriate. Adequate for a trivial tool, but not 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?

With 0% schema description coverage, the description should compensate by explaining dev_eui, but it never mentions the parameter at all. The name dev_eui is self-descriptive and consistent with sibling tools (device_get, device_delete, device_enqueue), which mitigates the gap somewhat, but the description itself adds zero parameter 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?

The description uses a specific verb ("Discard") with a specific resource ("queued downlink") and a clear scope ("every"), so the agent knows exactly what is acted upon. It implicitly differentiates from sibling tools like device_enqueue and device_queue_get, though it never names them explicitly.

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

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

Usage is implied — if an agent wants to clear a device's outbound queue, this is the tool — but there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as device_enqueue or device_queue_get. The description relies on the tool name and sibling list to convey context.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the core safety profile. The description adds a small behavioral nuance by defining the queue as containing downlinks 'waiting for (or pending confirmation from)' the device, but it does not disclose pagination, ordering, or limits.

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

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

A single sentence with no filler, front-loading the action and object. It is highly concise and easily parsed 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?

The tool is simple: one required parameter, read-only annotations, and an output schema. The description is nearly sufficient, but because the schema provides no description for dev_eui and the tool description does not bridge that gap, an agent unfamiliar with 'dev_eui' could be slightly uncertain. Still, for a trivial getter, it is largely complete.

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

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

Schema coverage is 0%, and the description does not mention dev_eui at all. The required string parameter's name is self-descriptive in a LoRaWAN context, but the description adds no detail about format, encoding, or how the device is identified, so the agent must rely entirely on the property name.

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

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

The description uses a specific verb ('Show') and a clear resource ('downlinks waiting for (or pending confirmation from) a device'). The state qualifier distinguishes it from related queue mutations like device_queue_flush and device_enqueue, though it does not name them explicitly.

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

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

No explicit when-to-use or alternative-routing guidance is provided. The description implies a read use case, but it does not mention device_queue_flush as the destructive alternative or device_enqueue as the write counterpart, leaving the agent to infer from sibling names.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context beyond the annotations by specifying that this is a one-shot read of a bounded in-memory buffer ('still holds', 'typically the last 10'), which helps the agent predict behavior and result size.

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. Every phrase contributes meaning: operation type, resource scope, bounded depth, and the optional events/frames distinction.

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, the presence of an output schema, and read-only annotations, the description covers the essential invocation context. Minor gaps remain about how to request frames vs events explicitly and what happens when no events are available, but the schema enum and output schema cover much of the remaining burden.

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 0%, so the description must help interpret parameters. It does indirectly: 'events (or frames)' maps to the kind enum, and 'for a device' maps to dev_eui. However, it never names the parameters explicitly or explains dev_eui format/requirements, relying on the schema's required field and enum.

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 ('one-shot look') and resource ('last few events or frames ChirpStack still holds for a device'), including the expected depth ('typically the last 10'). It does not explicitly name sibling tools, but 'one-shot' and 'still holds' help differentiate it from live/waiting or broader metrics tools.

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

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

The description implies use for a quick snapshot of a device's most recent buffered data, and 'typically the last 10' suggests limited depth. However, it gives no explicit when-to-use or when-not-to-use guidance, nor does it name alternatives such as wait_for_event or device_metrics.

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

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

The annotations already declare destructiveHint=true and readOnlyHint=false, so the description's 'Create or replace' aligns with the expected mutation behavior. It adds useful context about LoRaWAN 1.0.x key semantics, but it doesn't disclose whether replacing keys invalidates active sessions or has other operational consequences. The annotation covers the destructive nature, so this is adequate but not rich.

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

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

Two sentences, no filler, and the core purpose is front-loaded. The version-specific caveat is compact and directly useful for correct invocation.

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

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

For a 3-parameter mutation tool with destructive annotations and an output schema, the description covers the key nuance (LoRaWAN 1.0.x key placement) that an agent needs to call it correctly. It could add a note about impact on existing sessions, but the essentials are present.

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

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

Schema description coverage is 0%, so the description must compensate. It meaningfully explains that nwk_key carries the AppKey in LoRaWAN 1.0.x and implies app_key can be left empty for those devices. dev_eui's meaning is inferable from its name. This is good semantic help, though full value/format details are still left to the agent.

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 or replace') and a specific resource ('the OTAA root keys'), so an agent knows what the tool does. It doesn't explicitly distinguish this from siblings like device_activate or device_update, but the OTAA key focus is clear enough for selection.

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 about when to use this tool versus alternatives. The LoRaWAN 1.0.x note hints at a common scenario, but it doesn't say 'use this when provisioning OTAA keys' or mention when device_create/device_update/device_activate would be more appropriate.

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 only indicate that this is a non-read-only, non-destructive operation. The description adds genuinely useful behavioral detail: omitted fields retain their current values, and tags/variables maps are wholly replaced rather than merged. It does not clarify null-value behavior, but the core behavioral semantics are well disclosed.

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

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

Two sentences, no filler. The first sentence states the core behavior, and the second adds the critical map-replacement caveat. It is appropriately sized for a tool with 10 parameters and is easy to parse.

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

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

Given that the input schema enumerates all parameters, an output schema exists, and annotations cover the safety profile, the description supplies the missing operational semantics: partial update and replace-vs-merge behavior. Minor gaps remain around null handling and under-explained parameters like skip_fcnt_check, but nothing blocks a competent agent from using 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 0%, so the description carries the parameter-semantics burden. It explains the two non-obvious map parameters (tags and variables) and the general partial-update rule, but eight other parameters, including skip_fcnt_check and join_eui, rely entirely on their names for 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?

The description uses a specific verb and resource ('Update ... a device') and clearly distinguishes this from sibling tools by scoping it to partial updates of existing devices. The phrase 'only the given fields' also disambiguates it from device_create and device_delete.

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

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

The description gives clear context for when to use the tool: to modify selected fields of an existing device while preserving others. It does not explicitly name device_create/device_get/device_delete as alternatives or provide when-not-to-use exclusions, 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 signal that this is a non-read-only, non-destructive operation, and 'Register a gateway' confirms a creation action. The description adds one useful behavioral rule: location is set only when coordinates are given. However, it does not disclose side effects, duplicate behavior, or other consequences 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 definition is one tightly structured sentence with the core action first and the behavioral caveat second. There is no filler or repetition; 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 9-parameter create operation with zero schema field descriptions, the description lacks enough detail to reliably populate required parameters or understand optional tags and stats_interval behavior. The output schema covers return values, but parameter semantics and usage context remain incomplete.

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

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

Schema description coverage is 0%, and the description names none of the 9 parameters directly. Only 'coordinates' loosely maps to latitude, longitude, and altitude, while gateway_id, name, tenant_id, tags, stats_interval, and description remain semantically unexplained. This does not compensate for the low 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 opens with 'Register a gateway', which names an explicit action and resource. Since sibling tools include gateway_get, gateway_update, gateway_delete, and gateway_list, 'register' clearly identifies this as the gateway creation entry point.

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 'Register' implies this tool is for new gateways, but there is no explicit when-to-use guidance or comparison with gateway_update for modifying existing gateways. It also does not mention conditions like tenant context or duplicate handling, so usage context is only implied.

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

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

The annotations already declare destructiveHint=true, so the description does not need to restate that this operation is destructive. However, the description adds no additional behavioral context beyond the annotation—no mention of side effects, irreversibility, cascading effects, or authentication requirements. With annotations covering the destructive nature, a 3 is appropriate since the description provides minimal 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 concise sentence with no filler or redundancy. It is appropriately minimal for a simple delete operation. However, it could arguably be slightly more informative about the parameter or side effects, but the brevity is not a structural flaw—it is front-loaded and to the point.

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

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

Given the tool's complexity (one required parameter, a clear destructive intent, and an output schema), the description is adequate but not complete. It lacks any context about error Handling, idempotency, or what happens if the gateway does not exist. The presence of an output schema mitigates the need to describe return values, but the description still does not address potential failure modes or prerequisites, making it only minimally 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 0%, and the description does not mention the 'gateway_id' parameter at all. The schema only provides the type (string) and requirement, but no format, example, or clarification. Given the low coverage, the description was expected to compensate, but it offers no additional semantic value, leaving the parameter's meaning entirely to its self-explanatory name.

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

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

The description states a specific verb 'Delete' and a specific resource 'gateway', clearly distinguishing this from sibling read/create/update tools such as gateway_get, gateway_create, and gateway_update. The intended action is unambiguous and instantly maps to 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 provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. For instance, it does not mention that the gateway must exist, whether deletion is permanent, or if there are related resources that should be removed first. The agent is left to infer usage from the name and parameter alone.

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

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

Annotations already mark this as readOnly and non-destructive, and the description merely restates the read-only nature without adding context such as not-found behavior, authorization requirements, or data freshness. It adds no behavioral traits beyond what annotations provide.

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

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

The description is a single, front-loaded sentence with no filler or redundant information. Every word contributes to understanding what the tool does.

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 one-parameter read operation with an output schema, the description covers the core action and returned fields. However, it lacks explicit usage guidance and any parameter elaboration, leaving it adequate but not fully complete.

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

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

Schema description coverage is 0%, and the description does not elaborate on gateway_id or how it identifies the gateway. The parameter's purpose is inferable from its name, but the description adds no meaning beyond the schema's field definition.

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 operation (get) and resource (a gateway), and specifies that the result includes last-seen time and location. It communicates a read-one operation that is distinguishable from gateway_list, though it does not explicitly contrast with sibling tools.

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

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

The description gives no guidance on when to use this tool versus gateway_list, gateway_metrics, or other sibling tools. The intended use can be inferred from the name and the required gateway_id, but no conditions or alternatives are 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 the operation read-only and non-destructive. The description adds important beyond-annotation behavior: the all-tenants result depends on tenant_id being empty and the key having global admin privileges. This is meaningful auth/scoping 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 one sentence with no filler, front-loads the core action, and tucks the nuanced scoping condition into a parenthetical. Every word earns its place.

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

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

For a simple optional-parameter list operation with an output schema, the description covers the likely source of confusion: tenant scope and admin authorization. It could slightly improve by routing to gateway_get for single-lookup, but that is 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 0%, and the description compensates for the most important parameter, tenant_id, explaining its scoping effect. However, it provides no additional meaning for limit, offset, or search, though those are conventional list parameters.

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

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

The description states a specific verb and resource ('List gateways') and adds the tenant-scoping condition. It clearly distinguishes the tool from singular gateway_get and mutation tools without needing to open 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?

It gives a clear decision rule: empty tenant_id plus a global admin key returns gateways across all tenants. This is actionable context, though it does not explicitly name alternatives or exclusion conditions.

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

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

readOnlyHint=true and destructiveHint=false already establish the safety profile, so the description only needs to add useful behavioral context. It adds the default 24-hour lookback, but it does not clarify timezone handling, how aggregation affects results, or what 'status' refers to. It does not contradict 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 tightly written sentences with no filler. The returned metric dimensions are front-loaded, and the default time window is stated efficiently in a short 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?

For a read-only query tool with an output schema and self-descriptive parameter names, the description covers the returned dimensions and the default time window. However, it leaves open time format/zone details and aggregation semantics, so it is adequate but not fully complete for a 4-parameter 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 0%, so the description needed to compensate by explaining gateway_id, start/end format, and aggregation behavior. It only alludes to the default time window with 'last 24 hours' and does not explain any parameter details. Parameter names are self-descriptive, but the description itself adds almost no 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?

The description specifies the metric resource (gateway RX/TX packet counts and duty-cycle usage) and the grouping dimensions (frequency, DR, status), which clearly separates it from gateway_get and device_metrics. It lacks an explicit verb like 'retrieves' or 'returns', but the noun phrase and data detail make the function 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 is provided on when to use gateway_metrics versus device_metrics or other sibling tools, and no alternatives or exclusions are mentioned. The only contextual addition is a default 24-hour window, which is more about behavior than about choosing this tool over another.

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 that this is a mutating operation (readOnlyHint=false). The description adds valuable behavioral nuance by stating that only provided fields are updated and that supplying tags replaces the entire tag map. It does not cover auth or error behavior, but the annotation baseline lowers the burden.

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

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

Two short sentences, front-loaded with the core purpose and a necessary side-effect warning. No wasted words.

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

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

The description covers the essential purpose and the main side effect, and the output schema handles return values. However, with 8 parameters and no schema descriptions, it leaves gaps around null semantics, field units, and failure behavior, making it adequate but not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It adds the key partial-update rule and the specific tags-replacement behavior, which is the most non-obvious parameter semantic. However, most parameters get no individual explanation, and null-clearing behavior is not clarified.

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: 'Update only the given fields of a gateway.' This clearly distinguishes it from sibling tools like gateway_create, gateway_get, gateway_list, and gateway_delete.

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 'Update only the given fields' makes the intended use case clear: modifying an existing gateway without replacing the whole object. It does not explicitly name alternatives or exclusion conditions, but the context is unambiguous enough for an agent to select it appropriately.

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

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

Annotations only indicate readOnlyHint=false and destructiveHint=false, which adds little behavioral context. The description says 'Create' but does not disclose validation behavior, side effects, idempotency, authorization requirements, or what happens if a profile already exists. With weak annotations, more behavioral disclosure was needed.

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 main action is front-loaded, and the second sentence delivers the essential constraints (required fields and enum style) efficiently. 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?

Given the loose input schema and one free-form parameter, the description provides the key context an agent needs: required fields, naming convention, and enum format. An output schema is present, so return-value documentation is not required. It stops short of listing optional fields, but it is reasonably complete for a generic 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 coverage is 0% and the profile property is an open-ended object, so the description must compensate. It does so by explaining snake_case field naming, enum-by-name conventions, concrete examples, and the required field set. This adds substantial meaning beyond the empty schema, though a complete field list is still left to inference.

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 clear verb and resource ('Create a device profile'), and gives concrete details about the input representation. It does not explicitly distinguish itself from sibling tools like profile_update or profile_delete, but the action verb and resource make its purpose unambiguous.

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

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

The description implies usage: call this when creating a new device profile. It provides required fields and formatting guidance, but it does not explicitly state when not to use it or mention alternatives such as profile_update for modifying an existing profile. Usage context is clear enough but not fully explicit.

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

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

Annotations already flag destructiveHint=true and readOnlyHint=false. The description adds valuable context beyond annotations by disclosing a precondition: deletion fails while devices still use the profile. This helps the agent anticipate guardrails without contradicting the annotations.

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

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

The description is a single, efficient sentence with no filler. The core action is front-loaded, and the important failure condition is appended concisely.

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 one-parameter destructive operation with an output schema and destructiveHint annotation, the description covers the necessary context. The failure condition is the main behavioral nuance an agent needs, and nothing critical appears missing.

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

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

Schema description coverage is 0%, and the description does not explicitly explain the profile_id parameter. However, the singular parameter is self-evidently the identifier of the profile to delete, and the description establishes the semantic context. It adds some meaning but does not fully compensate for the undocumented 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 names a specific verb ('Delete') and resource ('device profile'), clearly distinguishing it from sibling tools like profile_update or profile_get. The parenthetical adds a key behavioral constraint rather than obscuring the purpose.

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

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

The description implies this tool is for removing a device profile, but it does not explicitly say when to choose it over profile_update or other profile operations. The failure condition hints that it should be used only when the profile is not in use, but no alternatives are named.

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 provide readOnlyHint=true and destructiveHint=false, and the description does not contradict them. It adds one behavioral detail (codec script is returned), but gives no additional context about response behavior, errors, or access requirements.

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 tightly written sentence, front-loaded with the core action and no filler. The codec-script detail is substantive and earns its place.

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

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

For a simple read-only get-by-id tool with an output schema and safety annotations, the description plus schema provide most of what an agent needs. It is slightly incomplete only in lacking guidance on choosing this over profile_list and clarifying profile_id.

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

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

Schema description coverage is 0%, so the description must compensate. It does not explain the meaning or expected format of profile_id, nor how to obtain a valid value, leaving the sole required parameter under-specified.

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

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

Description uses a specific verb ('Get') and resource ('a device profile') and adds the meaningful detail that the payload codec script is included. This clearly distinguishes it from listing or mutating profiles, so an agent can tell what the tool does.

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

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

There is no explicit when-to-use vs alternatives such as profile_list or profile_update. The intended use is implied by 'Get a device profile' and the singular resource, but the description does not state conditions 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the tenant-scoping behavior but does not disclose pagination behavior, result ordering, or search semantics. With annotations covering basic safety, a 3 is appropriate.

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

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

The description is a single, compact sentence with no filler. The verb and resource are front-loaded, and every word contributes to the core meaning.

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

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

For a simple read-only list tool with an output schema and clear annotations, the one-line description is nearly sufficient. However, it omits pagination/search behavior and any guidance on choosing this tool over sibling list/get tools, leaving some context for the agent to infer.

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 0%, so the description carries the burden of explaining parameters. It only weakly maps to tenant_id through 'of a tenant' and says nothing about limit, offset, or search. The parameter names are somewhat self-explanatory, but the description does not meaningfully compensate for the missing schema 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 action ('List'), a clear resource ('device profiles'), and a scope ('of a tenant'). This distinguishes it from profile_get by operation type, though it does not explicitly name sibling alternatives.

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

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

No guidance is provided about when to use this tool instead of related tools like profile_get, profile_list_vendors, or device_list. The intended usage is only implied by the name and description.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is fully covered. The description adds the server-scoping detail, but no extra behavioral traits such as pagination, ordering, or response specifics are mentioned. That additional detail is not required given the output schema exists and the operation is trivial.

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 with no filler. Every word contributes meaning, and it is appropriately sized for a zero-parameter list tool.

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

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

For a simple list operation with no parameters, output schema present, and read-only annotations, the description is complete. It tells the agent exactly what is listed and where, and no additional context is necessary to invoke the tool correctly.

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

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

The tool has zero parameters, and schema coverage is 100%, so the baseline of 4 applies. The description correctly does not invent parameter information; nothing more 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 uses a specific verb ('List') with a clear resource ('ADR algorithms') and scope ('on this server'). This distinguishes it from sibling tools like profile_list (list profiles) and profile_list_vendors (list vendors), so an agent can immediately tell what it does.

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

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

The description clearly implies when to use the tool: when you need to enumerate the ADR algorithms supported by the server. It does not explicitly name alternatives or exclusions, but for a simple read-only list with no parameters, the context is sufficient to guide selection.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false. The description adds a small amount of context by narrowing the source to the imported device-profile catalogue, but does not disclose behavior like pagination, ordering, or filtering beyond the limit/offset parameters.

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

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

The description is a single concise sentence with no filler. It front-loads the key action and resource, making it easy to parse quickly.

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

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

For a simple read-only listing tool with an output schema, the description is largely complete. It names the resource, source catalogue, and safety profile via annotations; the main gap is lack of explicit pagination or usage-distinction details.

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?

Input schema coverage is 0% and the description provides no parameter explanations. The names 'limit' and 'offset' are conventional and self-explanatory, but the description does not compensate for the lack of schema descriptions or clarify pagination semantics.

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

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

The description uses a specific verb ('List') and resource ('vendors') and adds a clear source scope ('imported device-profile catalogue'). It distinguishes this tool from sibling profile_list, which presumably lists profiles rather than vendors.

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

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

The description gives clear context about when to use the tool: to enumerate vendors from the imported device-profile catalogue. It does not explicitly mention alternatives or exclusions, but the resource scoping is strong enough to guide selection.

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

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

Annotations only mark the tool as non-read-only and non-destructive, which provides minimal behavioral info. The description adds meaningful context: it is a partial replacement ('only the payload codec'), it imposes script structure requirements (decodeUplink/encodeDownlink), and using runtime NONE disables the codec. This covers key behavioral traits 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 concise sentences with no filler. The core purpose is front-loaded, and the second sentence packs essential usage details and workflow context into a compact form. 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?

Given the tool is a mutating operation with an output schema (not shown), the description covers the important calling requirements: script necessity and format for JS, how to disable, and a workflow hint. It does not mention error handling or prerequisites like profile existence, but those are less critical and the output schema will clarify return behavior. Overall, it is complete enough for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It does: it explains that script is required for runtime JS and must define specific functions, and it clarifies that runtime NONE turns off the codec. profile_id and CAYENNE_LPP are not elaborated, but their purpose is evident from the enum and name. The description adds substantial parameter meaning beyond the raw 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: 'Replace only the payload codec of a profile.' This clearly distinguishes it from broader profile operations like profile_update, and the qualification 'only' signals its narrow scope. The agent knows exactly what this tool does.

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 usage context ('Iterate here while watching uplinks with capture_read') and parameter-level guidance (script requirements for runtime JS, NONE to turn off), but does not explicitly state when to prefer this over alternatives like profile_update or when not to use it. The guidance is implied, not explicit about tool selection.

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

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

Beyond the annotations, the description discloses non-obvious behavior: omitted fields are kept, and map/repeated fields (tags, measurements) replace the entire field rather than merging element-wise. This is valuable because the schema alone gives no such semantic detail; no contradiction with readOnlyHint=false and destructiveHint=false.

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 packs the core merge behavior, the exception for map/repeated fields, and the omitted-fields rule into two efficient sentences. It is front-loaded with the primary action and contains no filler.

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

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

Given the output schema exists, return values are not the burden here. The description covers the essential merge/replace semantics that an agent needs to invoke the tool correctly on a 2-parameter nested-object call. It falls slightly short of a 5 because it does not mention how unknown or invalid DeviceProfile fields in `changes` are handled.

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

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

With 0% schema description coverage, the description compensates by defining the `changes` object as a partial update whose omitted fields are preserved and whose map/repeated fields overwrite wholesale. It does not explicitly describe `profile_id`, but the name and required status make its role obvious.

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 'Merge the given DeviceProfile fields into an existing profile', naming a specific verb (merge), a resource (DeviceProfile fields into an existing profile), and the operation semantics. This clearly distinguishes it from profile_create, profile_delete, and profile_set_codec among the 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?

It establishes the use case: apply a partial set of DeviceProfile fields to an existing profile while preserving unspecified fields. It does not explicitly name alternatives or negative conditions, but the merge-vs-replace context makes when to use it clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond this: version and regions may be null/empty when using an API key instead of a user session, which is a useful expectation-setting detail for interpreting results.

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

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

The description is two sentences with no filler. The primary purpose is front-loaded, and the caveat about version/regions is compactly appended. 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 zero-parameter, read-only info tool with an output schema and annotations covering safety, the description is complete. It tells the agent what the tool does, what to expect regarding null/empty fields, and no additional context is needed to invoke it correctly.

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

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

The tool has zero parameters and the schema already documents this completely with 100% coverage. There is no parameter-level information needed; the baseline for a no-parameter tool is 4, and the description appropriately adds no irrelevant parameter details.

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

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

The description states a specific purpose: checking the connection and API key validity, and mentions the resource (ChirpStack server info). It is clearly distinguishable from the sibling tools, which are all device, application, profile, gateway, capture, or queue operations. No ambiguity remains about what this tool does.

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

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

The description clearly implies when to use the tool: when you need to verify connectivity or authenticate with the ChirpStack server. It does not explicitly discuss when not to use it, but there are no obvious overlapping sibling tools, so the context is sufficient without 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?

Beyond the readOnly/destructive annotations, the description discloses the critical 'live only' semantic: replayed events never satisfy the wait regardless of arrival timing. It also exposes blocking behavior, the 60-second cap, and optional event-type filtering, giving the agent a clear behavioral model.

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

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

Three sentences with no filler. The core blocking behavior is front-loaded, the live-vs-replayed subtlety is explained in the middle, and the sibling routing closes it out. Every sentence contributes directly to correct usage.

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 blocking tool with nuanced live-event semantics, this description is complete. It covers what counts, what does not count, the timeout constraint, optional filtering, and the correct alternative. An output schema exists, so return-value details are not the description's burden.

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 0%, so the description must compensate. It does this well by listing valid event types and imposing the timeout max of 60 seconds. The dev_eui parameter is not explained, but its meaning is fully inferable from the tool name and sibling context.

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 ('Block until') and resource ('device emits a live event'), then clarifies the optional event types and timeout behavior. It also explicitly differentiates itself from device_recent_events, which is the key sibling an agent might confuse it with.

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 unambiguous: wait for live events only, and if you need replayed/history events, use device_recent_events. This direct alternative routing is exactly what an agent needs to choose the correct tool.

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