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

No annotations are provided, so the description carries full burden. It describes the return dictionary (status, device, task_id, message) and provides examples. It could disclose more about error handling or what happens if a device already exists, but overall it is transparent about core behavior.

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

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

The description is well-structured with Args, Returns, and Examples sections. It is informative without being overly verbose, though it could be slightly more concise by merging some explanatory lines.

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

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

Given the complexity (10 parameters, no annotations) and the presence of an output schema, the description is comprehensive. It covers device types, required vs optional parameters, return format, and examples. Minor omission: it does not explain possible values for mgmt_mode beyond the 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?

The schema has 0% description coverage, so the description must add meaning for all parameters. It thoroughly explains each parameter (adom, name, ip, serial_number, admin_user, admin_pass, description, platform, mgmt_mode, flags) with defaults and examples, far exceeding basic schema information.

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 explicitly states 'Add a new device to FortiManager' and distinguishes between adding a real device (with IP) and a model device (with serial number). This effectively differentiates it from sibling tools like add_model_device and add_devices_bulk.

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

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

The description provides clear context on when to use the tool by detailing two use cases (real device with IP, model device with serial number) with examples. However, it does not explicitly state when not to use it or mention alternatives like add_model_device, which could lead to slight ambiguity.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the add runs as a background task, that requested_count is not a count of devices actually added, and that per-device results only exist after task completion. It omits permission/auth requirements and partial-failure behavior, which are the remaining material gaps for a mutation tool.

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

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

Structured as statement, Args, Returns, Example, and the essential facts are front-loaded. The second sentence ('Registers multiple devices at once for efficiency') is largely redundant with the first, and the Returns block partly duplicates the output schema, but the worked example earns its space for a nested-dict payload.

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 bulk mutation tool with an output schema present, the description is nearly sufficient: it covers tenant scoping, the device payload shape, and the asynchronous task semantics. It stops short on operational prerequisites (ADOM locking, existing device registration, permission requirements) that an agent would need before firing the call.

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%, so the description must compensate and largely does: every field of the nested device dict is enumerated with a required marker on name, plus adm_usr/adm_pass/platform_str meanings the bare schema would leave opaque. The flags parameter is only illustrated with a single example value (["create_task"]) without explaining what other flags are valid.

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

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

The first two sentences state a specific verb (add/register) and resource (multiple devices / devices in bulk) scoped to FortiManager, and the ADOM arg confirms the tenant scope. It does not explicitly distinguish itself from the single-device siblings (add_device, add_model_device) or from add_devices_to_group_bulk, which a reader must infer.

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?

'Registers multiple devices at once for efficiency' implies the bulk-vs-single tradeoff, but there is no explicit when-to-use statement, no named alternative, and no prerequisites (ADOM lock, credential validity, whether devices must be pre-registered). Usage context is implied rather than stated.

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

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

With no annotations, the description carries the full burden and does so well: it declares the operation non-destructive, preserves existing members, explains the same-VDOM constraint, and warns that requested_count is not a count of changed memberships because FortiManager gives no per-member result.

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

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

The description is front-loaded with the core operation, then uses clear Args, Returns, and Example sections. The return-value caveat is not padding; it prevents a likely misinterpretation of requested_count.

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 bulk mutation tool with no annotations, 0% schema parameter descriptions, and an output schema, the description supplies the missing behavioral semantics, parameter meanings, expected return shape, and the relevant alternative 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 must compensate. It documents all four parameters with meaning: ADOM name, target device group name, list of device names, and VDOM with its default of 'root', plus the same-VDOM caveat.

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: adding multiple devices to a device group in one call. It clearly distinguishes this bulk operation from the singular sibling add_device_to_group by explaining the same-VDOM constraint.

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

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

It explicitly states that all devices are added on the same VDOM and directs the caller to add_device_to_group individually for devices needing a different VDOM. That is a concrete when-to-use-this-vs-alternative rule.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the operation is non-destructive and describes the return status/message keys, but it does not mention permission requirements, idempotency, behavior when the device is already in the group, or error 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?

The description is front-loaded with the core action and then uses compact Args/Returns/Example sections. The structure is easy to scan, and the example adds practical clarity without excessive verbosity.

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 single-device add operation, the description covers parameters, the non-destructive behavior, return keys, and an example. An output schema exists, so return details need not be exhaustive, but missing permission/error context keeps it from being 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 labels all four parameters and states the vdom default of 'root', but it does not clarify constraints, expected formats, or ADOM/device/group naming rules.

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

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

The description states a specific verb and resource: 'Add a single device to a device group.' The word 'single' distinguishes it from the sibling bulk tool add_devices_to_group_bulk, so an agent can select it 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 gives clear context for adding one device and notes that existing group members are preserved, making the non-destructive nature explicit. It does not explicitly name alternatives such as add_devices_to_group_bulk or remove_device_from_group, so there is no full when/when-not routing guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the resulting entry's shape (no VDOM) and the success/error status contract, but it omits prerequisites such as whether the parent and child groups must already exist, whether the call is idempotent, what happens on duplicate nesting, and required permissions.

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

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

Front-loaded with the one-line purpose, then the useful VDOM distinction, then args and a concrete example. The Returns block largely restates the output schema, so a small amount of content is redundant, but nothing is bloated.

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

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

For a simple three-string, all-required mutation with an output schema present, the description covers purpose, arg meaning, and example. The remaining gap is failure semantics (already nested, missing group, locked ADOM), which an agent would want before calling.

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 schema only carries bare titles, so the Args block is doing real work: it clarifies ADOM scoping and, importantly, the parent/child directionality ('group that will contain' vs 'group to nest inside'). It stops short of adding naming format or cross-ADOM constraints.

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

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

States a specific verb+resource pair: nest a device group inside another device group. The VDOM note distinguishes a nested-group membership entry from a device entry, which implicitly separates this from add_device_to_group, but it never names the sibling tools (add_device_to_group, remove_group_from_group) directly.

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

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

Usage context is implied by the operation (creating a nested-group membership) but there is no explicit when-to-use / when-not-to-use guidance and no pointer to the obvious complements, add_device_to_group or remove_group_from_group, which an agent could easily confuse with this call.

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

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

With no annotations, the description carries the full burden and does well: it discloses that this calls the sub-resource ADD endpoint, that FortiManager auto-assigns entry_id when omitted, and that entries are appended to an existing sensor's entries list. It stops short of stating auth/permission requirements, duplicate-entry behavior, or whether a commit_adom is required for changes to take 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?

Front-loaded with purpose, then usage semantics, then Args/Returns/Examples – well structured for an 11-parameter tool. The paragraph contrasting the nested sub-resource with update_device_wtp_profile_radio's read-modify-write is interesting rationale but does not help an agent decide or invoke, and the examples partly restate the Args docs.

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

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

For an 11-param mutation tool with no annotations, the definition covers inputs, return shape, and the two usage patterns thoroughly. Missing only secondary but real facts: whether a subsequent commit_adom is needed, and what happens on conflicting/duplicate entries for the same signature.

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 and it does: every one of the 11 params is documented with meaning, allowed values ('pass', 'block', 'reset', 'default'), defaults, and the entry_id range (0-4294967295). This adds substantial meaning the bare schema does not provide.

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 ('Add a signature filter/override entry to an IPS sensor') and explains it writes to the nested 'entries' sub-collection of the sensor. The distinction from create_ips_sensor, list_ips_sensor_signature_overrides and remove_ips_sensor_signature_override is implied clearly, and differentiates from update_device_wtp_profile_radio by mechanism.

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

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

Explicitly gives the two mutually exclusive usage modes: pass `rule` for specific signature overrides, or omit it and use `severity`/`default_action`/`default_status` for a broad filter entry with concrete examples of both. It also states the precondition that the sensor must already exist and points to create_ips_sensor.

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

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

No annotations provided, so description carries full burden. It describes the tool's purpose (adding a model device) but does not disclose behavioral traits like permissions needed, side effects, or that it does not add an actual device. The description is adequate but lacks depth.

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 well-structured: introductory sentence, conceptual explanation, then clear Args, Returns, and Example sections. Every part is useful and front-loaded.

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

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

Given the presence of an output schema (mentioned in context), the description still includes a helpful Returns section. It covers purpose, parameters, returns, and an example. Could mention prerequisites like ADOM existence, but otherwise complete.

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

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

Schema has 0% description coverage, but the description provides clear explanations for all 6 parameters in the Args section, including default values and an example serial number. This adds significant 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 clearly states 'Add a model device for offline provisioning' and explains that model devices allow pre-configuring policies and settings before the actual device connects. This distinguishes it from sibling tools like add_device (adds actual device) and add_devices_bulk.

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

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

The description mentions usefulness for zero-touch provisioning workflows but does not explicitly say when not to use this tool or compare it directly with alternatives like add_device. Usage context is implied 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?

With no annotations, the description still discloses that this is a two-phase operation (create does not start capture), that FMG auto-assigns the capture_id, and the filter semantics when optional args are omitted. It does not mention permissions, ADOM locking, capture resource consumption, or expiry, which are the remaining behavioral gaps for a mutating tool.

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

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

Front-loaded with the one-line purpose, then Args/Returns/Example in a predictable layout. The doctest example is slightly long but earns its place by demonstrating the create-then-start chaining. Minor redundancy between Returns and the example's re-demonstration of the same keys.

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

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

For an 8-parameter creation tool with zero schema descriptions and no annotations, the definition covers purpose, all parameters, defaults, return shape, and the required follow-up call. An agent has everything needed to invoke it correctly and act on the result.

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

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

Schema coverage is 0%, so the description carries the full burden and does: every one of the 8 parameters is explained, including the crucial format details the schema lacks ('port' as a string like "80" or "1-1024", 'protocol' as a string IP protocol number, 'host' matches any host if unset). Defaults and the FMG-default max_packet_count of 4000 are also given.

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 ('Add a new FortiManager packet capture definition') and scopes it precisely: traffic 'originating or destined to the FortiManager itself,' which separates it from the device-sniffer siblings like create_device_sniffer. An agent can pick the right tool without opening a 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 explicitly states the definition is created but not started and directs the agent to call start_packet_capture() with the returned capture_id, which is exactly the confusing part of this workflow. It doesn't explicitly name when to prefer create_device_sniffer or create_device_on_demand_sniffer, so the sibling routing is implied 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?

Basic behavioral info: associates package with devices for later installation. Does not disclose side effects, permissions, or safety profile. No annotations exist, so description carries the burden but provides limited detail.

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

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

Concise and well-structured: brief statement, then Args, Returns, and Example. No redundant information, every sentence adds value.

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

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

Covers purpose, parameters, return values, and example. However, lacks details on prerequisites (e.g., existence of ADOM/package/devices) and does not clarify synchronous/asynchronous behavior. Output schema is described in Returns.

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?

While schema coverage is 0%, the description adds meaning by listing and describing each parameter (adom, package, devices with format example), compensating 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 clearly states 'Assign a policy package to devices.' with specific verb and resource, distinguishing it from sibling tools like assign_sdwan_template or assign_system_template.

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

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

No guidance on when to use this tool versus alternatives. It lacks context on prerequisites, when not to use, or comparison with similar assign 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?

No annotations are provided, and the description does not disclose behavioral traits such as whether existing assignments are overwritten, the impact on device state, or required permissions. The return type 'Assignment result' is vague and lacks detail.

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

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

The description is short and front-loads the purpose. The Args and Returns sections are clear and structured efficiently, with no unnecessary words.

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

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

For a mutation tool with no annotations, the description lacks completeness. It does not cover error conditions, side effects, prerequisites, or the format of the return value. The agent has insufficient context to use the tool safely.

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 adds value by listing parameters and stating the default value for 'vdom'. However, it does not explain the meaning of each parameter (e.g., what ADOM is) or provide format constraints beyond 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 clearly states the verb 'Assign' and resource 'SD-WAN template to a device', distinguishing it from bulk and system template assignments. However, it does not explicitly mention that it assigns to a single device, which is implied by the name and bulk sibling.

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

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

No guidance on when to use this tool versus alternatives like assign_sdwan_template_bulk, assign_system_template, or assign_template_group. No prerequisites or preconditions are mentioned, leaving the agent to infer usage context.

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

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

With zero annotations, the description carries the full behavioral burden, and it delivers the single most important caveat: 'requested_count' is not a count of successful assignments, because FortiManager returns no per-device result for this scope-member ADD and the client raises on any non-zero code. That is a real behavioral disclosure an agent cannot get from the schema. It stops short of other mutation risks — whether reassignment overwrites an existing template, whether failures are partial, or whether a commit_adom is required afterward.

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

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

Front-loaded with a single clear purpose sentence, followed by compact Args and a focused Returns caveat. The one blemish is the internal reference '(same shape as #78's device-group bulk tools)', which is noise for an agent, though the caveat it annotates is worth the 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?

An output schema exists, so the Returns block is partly redundant — though the requested_count warning adds meaning beyond it. What's missing for a bulk mutation tool with no annotations is operational context: overwrite/reassignment behavior, partial-failure semantics, and whether a subsequent commit_adom or install is needed for the assignment to take effect.

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, and it mostly does: it glosses all three parameters and, critically, supplies the concrete element shape for devices — '[{"name": "dev1", "vdom": "root"}]' — which the bare schema (array of string-keyed objects) does not reveal. It omits whether vdom is optional, whether devices must already exist in the ADOM, and whether the template name must come from list_sdwan_templates.

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

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

States a specific verb, resource and scope: 'Assign an SD-WAN template to multiple devices.' The 'multiple devices' framing implicitly distinguishes it from the single-device sibling assign_sdwan_template, but the description never names that sibling or the unassign counterpart, so the differentiation is only inferable.

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 statement of when to use this versus assign_sdwan_template (single) or assign_system_template_bulk. Usage is implied by 'multiple devices' in the first line, but there are no preconditions, no exclusions, and nothing about ADOM lock or commit requirements that would guide an agent choosing among the assignment 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?

No annotations are present, so the description must fully disclose behavioral traits. It only states the action without mentioning side effects (e.g., overwriting existing assignments), authorization requirements, whether the operation is synchronous, or error handling. This severely limits an agent's ability to predict the tool's behavior.

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

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

The description is extremely concise: one sentence for purpose, followed by a compact parameter list, and a one-line return statement. It is front-loaded and contains no superfluous information, making it easy for an agent 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?

Despite having an output schema (context signal), the description only states 'Returns: Assignment result' without specifying the structure (e.g., success flag, task ID, error details). The tool has 4 parameters and no enums, but the description lacks behavioral context (e.g., prerequisites, effects on device state). An agent would need additional information to use this tool reliably in a workflow.

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 'Args' section adds meaningful descriptions beyond the input schema's titles (e.g., 'ADOM name', 'System template name', 'Device name to assign', 'VDOM name (default: root)'). With schema description coverage at 0%, this compensation is effective, though some parameters (like adom) could benefit from more precise context (e.g., which ADOM scope applies).

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

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

The description clearly states the tool's action: 'Assign a system template to a device.' This specific verb+resource pairing distinguishes it from sibling tools like assign_sdwan_template and assign_system_template_bulk, which handle different template types or bulk 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 provides no guidance on when to use this tool versus alternatives (e.g., assign_system_template_bulk for multiple devices, assign_template_group for group assignments). An agent would have to infer context from the parameter list, which is insufficient for informed selection.

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

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

With no annotations, the description carries the full burden, and it delivers the single most important behavioral fact: success=True is not a per-device success count, FortiManager returns no per-device result for this scope-member ADD, and the client raises on any non-zero code. That is a genuine partial-failure disclosure an agent could not infer elsewhere. It still omits lock requirements, overwrite behavior for devices already bound to another template, and idempotency.

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 purpose is front-loaded in one clean sentence, but the Returns block is a docstring dump that partly restates the output schema and includes an internal artifact reference ('same shape as #78's device-group bulk tools') that costs tokens without helping an agent. The core caveat inside it is worth keeping; the packaging is not.

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

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

For an unannotated bulk mutation touching many devices, the description covers the success-semantics trap well but leaves out acquisition of an ADOM lock, whether existing assignments are replaced, and what happens to other devices if one fails. Adequate to call correctly, thin on consequences.

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%, so the description must compensate, and it does for the hardest parameter: the devices array is shown with its key structure and a concrete example ({"name": "dev1", "vdom": "root"}), which the schema entirely lacks given its bare additionalProperties:string items. 'adom: ADOM name' and 'template: System template name' add little beyond the field names, keeping it below 5.

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 opening sentence states a specific verb and resource plus the bulk scope ('Assign a system template to multiple devices'), which implicitly separates it from the singular assign_system_template and from assign_sdwan_template_bulk. It never names the sibling alternative explicitly, so the differentiation is inferable rather than stated.

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

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

Usage is only implied through the word 'multiple' -- an agent can guess that assign_system_template is the single-device path, but the description never says so, nor does it state prerequisites such as needing the ADOM unlocked or the template to already exist. No when-not guidance at all.

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

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

With no annotations, the description must fully convey behavioral traits. It states only that the tool 'assigns', which implies a create/update operation, but does not disclose idempotency, destructiveness, locking requirements, or whether the assignment replaces existing ones. This is insufficient for safe invocation.

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 concise with a clear structure: one-line purpose, a bullet-like list of arguments, and a returns line. No extraneous information, though the returns line adds minimal value.

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

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

Given 4 parameters, no annotations, and a sparse description, the tool definition lacks completeness. It does not explain error conditions, required object existence (e.g., template_group must exist), or ADOM context. The returns line is vague. An agent would struggle to use this tool reliably without additional documentation.

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 add meaning beyond parameter names. It merely lists the parameter names (adom, template_group, device, vdom) without explaining their roles or constraints. The schema already provides these names, so no added value.

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 ('assign') and the resource ('template group to a device'), making the core purpose understandable. However, it does not differentiate from sibling tools like assign_package or assign_system_template, which share the same verb-resource pattern.

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

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

No guidance is provided on when to use this tool versus alternatives (e.g., assign_package for provisioning templates). There are no prerequisites, context, or exclusions mentioned, leaving the agent without decision support.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the profile is read, the VAP is appended, vap-all is switched to manual, and existing VAPs are preserved. It does not mention permissions, rate limits, or whether a commit/install is required afterward.

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

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

The description is front-loaded with the core effect, then structured into Args and Returns. Every sentence adds useful information about behavior or parameters, with no wasted text.

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

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

The definition is strong for a mutation tool with no annotations: it explains the side effects, idempotent handling of existing VAPs, parameters, and return result. It is only missing workflow context such as whether changes must be committed/installed or what permissions are required.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: every parameter is explained, including device, profile, VAP name, radios with the 1-3 range and default, and VDOM with its default. The only minor tension is that the schema shows radios default null while the description says default [1, 2].

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: add a VAP/SSID to a FortiAP profile's radios so it is broadcast. It is clearly distinguishable from nearby CRUD tools, though it does not explicitly name alternatives such as update_device_wtp_profile_radio.

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

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

The description explains the effect of using the tool (appending the VAP and switching vap-all to manual), which implies when it is appropriate. However, it does not state when to use this versus alternatives like update_device_wtp_profile_radio or create_device_vap, nor does it give any 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?

No annotations are provided, so the description must carry the full burden of behavioral transparency. It states 'Creates a copy' indicating a write operation, but it does not disclose important behaviors such as whether existing packages with the same name are overwritten, if the operation is idempotent, or any required permissions. The return format is described, but side effects are understated.

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 reasonably concise and well-structured with a clear docstring format (Args, Returns, Example). It includes only necessary information without redundancy. However, the example is a bit lengthy but adds value, so not penalized heavily.

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 and the presence of an output schema in the description, the context is fairly complete. It covers the function, all parameters, return structure, and an example. It could improve by mentioning preconditions (e.g., the source package must exist) or error behavior, but overall it is adequate.

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 0% description coverage, so the description's parameter details ('adom: ADOM name', 'package: Source package name', 'new_name: Name for the cloned package') add essential meaning beyond the schema. While concise, these descriptions compensate for the lack of schema annotations, meeting the baseline expectation for 0% 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 clearly states 'Clone a policy package. Creates a copy of an existing package with all its policies.' It uses a specific verb ('clone') and resource ('policy package'), and it distinguishes from siblings like create_package or delete_package by specifying that it duplicates an existing package.

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

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

The description implies when to use this tool (when you want to duplicate a package), but it does not explicitly state when not to use it or mention alternatives such as create_package. No guidance on prerequisites or comparisons is provided, so usage guidance 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?

No annotations are provided, so the description carries the full burden for behavioral disclosure. It states that commits persist pending changes and is required before unlock, which is essential for a commit tool. However, it does not mention side effects, permissions, idempotency, or error handling.

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

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

The description is extremely concise, with a single-sentence functional description, a critical usage note, and clearly separated args/returns sections. Every sentence adds value with no wasted words.

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

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

For a simple commit tool with one parameter and an output schema, the description covers the essential purpose, usage timing, and return format. It could mention error conditions or prerequisites, but is largely complete given the tool's simplicity.

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

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

The schema description coverage is 0%, so the description must compensate. It describes the single parameter 'adom: ADOM name to commit', which adds minimal context beyond the schema property name and type. It does not provide format, constraints, or examples.

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 'Commit changes to an ADOM' using a specific verb and resource, and explicitly mentions 'Saves all pending changes made to the ADOM.' It also distinguishes from sibling tools like lock_adom and unlock_adom by specifying the required order of operations ('Must be called before unlocking to persist changes').

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

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

The description provides clear guidance on when to use the tool: 'Must be called before unlocking to persist changes.' It implies usage after making changes and before unlocking, but does not explicitly exclude other scenarios or mention 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?

With no annotations provided, the description carries the full burden. It discloses that FQDN addresses are resolved dynamically, which is a key behavioral trait. However, it omits details on permissions, side effects, or return value behavior beyond the schema.

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

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

The description is well-organized with a docstring structure: summary, behavioral note, Args, Returns, and Example. Every sentence adds value, and it is appropriately sized with no wasted words.

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

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

The tool has an output schema, and the description includes the return structure. It also mentions dynamic resolution behavior. For a create function, this covers essential context, though error handling and prerequisites are not addressed.

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 lists all parameters with brief explanations, e.g., fqdn: 'Domain name (e.g., "www.example.com")'. This adds meaningful context beyond the raw schema property types.

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 ('Create an FQDN ... address object') and the resource (FQDN address object). Among siblings like create_address_host and create_address_subnet, it uniquely identifies its focus on fully qualified domain names.

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

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

The description notes that FQDN addresses are resolved dynamically, which guides when to use this tool. It provides a concrete example but does not explicitly contrast with alternatives or list when not to use it.

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

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

No annotations are provided, so the description fully explains what the tool does: creates an address group, lists parameters, and specifies the return format. It could mention idempotency or error cases, but overall behavior is clear.

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 well-structured with clear sections for purpose, args, returns, and an example. Every sentence adds value, and it is concise.

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 and the presence of siblings, the description fully covers what an agent needs to know: input requirements, output format, and a usage example. It is 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 compensates by explaining each parameter (adom, name, members, comment) and provides a concrete example. This adds significant meaning beyond the schema.

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

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

The description clearly states 'Create an address group' and distinguishes it from siblings like create_address_fqdn or create_address_subnet by specifying it groups address objects. The example reinforces 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 usage for creating address groups but does not explicitly state when to use this tool versus other address creation tools. No alternatives or exclusions are mentioned.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention idempotency, side effects, authentication requirements, or what happens on duplicate IPs. The return format is described, but safety and mutability traits are missing.

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 structured with Args, Returns, and Example sections. It is longer than minimal but every part adds value: purpose, parameter explanations, return format, and a concrete example. No redundant sentences.

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

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

Given the tool has 4 parameters (3 required) and an output schema, the description covers parameters, provides an example, and describes the return value. It is complete for a creation tool, though behavioral context is missing. The presence of an output schema in context reduces the need to explain return values, but the description does it anyway.

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%, but the description compensates by explaining each parameter: adom (ADOM name), name (object name), ip (with example), comment (optional). The return schema is also described in text. This adds significant meaning 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 explicitly states 'Create a host address object (single IP)', providing a specific verb and resource. The tool name includes 'address_host', and the description clarifies it's for single IP addresses, distinguishing it from siblings like create_address_fqdn or create_address_range.

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

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

The description does not explicitly mention when to use this tool over alternatives. While the purpose 'single IP' implies the use case, there is no guidance on when not to use it or comparison with other address creation tools. The example provides context but not explicit usage rules.

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

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

No annotations provided, so description carries full burden. It describes creation, required parameters, and return format, but lacks details on idempotency, duplicate handling, or side effects.

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 well-structured with Args, Returns, and Example sections. It is concise and front-loaded with the main purpose, earning its place without waste.

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 (5 parameters, output schema), the description covers inputs and outputs well. It lacks prerequisites (e.g., ADOM existence) but is largely complete for a creation tool.

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

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

Schema description coverage is 0%, but the description provides clear explanations for all parameters (adom, name, start_ip, end_ip, comment) and includes an example, adding significant meaning beyond the schema.

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

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

The description clearly states 'Create an IP range address object.' and distinguishes from siblings like create_address_fqdn, create_address_host, etc., which are listed among 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 explains what the tool does but does not provide explicit guidance on when to use it vs. alternatives (e.g., create_address_host). Usage context is implied but not stated.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the creation action and return format, without addressing potential side effects, permissions, or constraints (e.g., handling duplicates, overwrite behavior). This is minimal transparency for a mutation tool.

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

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

The description is well-structured as a docstring with clear sections (Args, Returns, Example). It is comprehensive without being verbose, though the opening line could be slightly more concise. Every sentence adds value.

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

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

Given the tool's simplicity (4 parameters, output schema defined), the description provides a complete picture: what it does, required inputs, acceptable formats, and expected return values. It lacks edge-case behavior (e.g., duplicate handling) but is sufficient for standard use.

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

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

The schema has 0% coverage (no descriptions), but the description compensates fully by explaining each parameter: adom, name, subnet (with example formats), and comment (optional). This adds significant meaning beyond the schema's bare titles.

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 explicitly states 'Create a subnet/network address object,' using a specific verb+resource. Among sibling tools like create_address_fqdn, create_address_host, etc., it clearly distinguishes this tool as specializing in subnet addresses.

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 for creating subnet addresses by specifying the subnet parameter format (CIDR or netmask). However, it does not provide explicit guidance on when to use this tool versus alternatives (e.g., for FQDN or host addresses), nor does it mention when not to use it.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose permissions, side effects, duplicate-name handling, ADOM lock requirements, or whether a subsequent commit is needed; it mainly restates the mutation and return shape already implied by the name and output schema.

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

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

The description is front-loaded with the purpose and then structured into Args, Returns, and Example sections. It is somewhat verbose because the Returns section duplicates output schema information, but the parameter documentation is necessary given 0% schema coverage.

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 six-parameter create tool with no annotations and no schema descriptions, the description provides all parameter meanings and an example call. It is incomplete on behavioral and usage context, especially mutation prerequisites, but sufficient to invoke the tool correctly.

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

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

Schema description coverage is 0%, but the description compensates by explaining every parameter, including allowed values for feature_set ("proxy" or "flow"), scan_mode ("default" or "legacy"), and av_virus_log ("enable" or "disable"). This adds substantial meaning beyond the schema titles.

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

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

The description states a specific verb and resource: "Create an antivirus profile." This clearly distinguishes it from sibling operations such as update_antivirus_profile, get_antivirus_profile, delete_antivirus_profile, and list_antivirus_profiles.

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 by the create verb and the example invocation, but there is no explicit guidance on when to use this versus update_antivirus_profile, prerequisites such as ADOM locking, or whether a commit is required afterward. It gives enough context to attempt the call, but not full routing guidance.

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

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

With no annotations, the description carries the full behavioral burden. It discloses return keys and allowed values for optional flags, but does not mention permissions, whether a commit is required afterward, duplicate-name handling, or other mutation-specific side effects.

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

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

The description is front-loaded with the purpose and uses a clean Args/Returns/Example structure. It is somewhat verbose because the Returns section duplicates output information, but the example earns its place by showing a realistic 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?

The description covers all parameters, return keys, and an example, which is enough for basic invocation. However, for a mutation tool with no annotations, it omits lifecycle context such as commit requirements, permission needs, and behavior on duplicate list names.

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 names all six parameters and adds meaningful semantics, especially allowed values such as "enable"/"disable" and "pass"/"block" for the optional fields.

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

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

The description states a specific verb and resource: "Create an application-control list." This clearly distinguishes it from sibling read/update/delete operations, though it does not explicitly name those alternatives.

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

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

The description does not explain when to create a new list versus using update_application_list or deleting an existing one. The example shows how to invoke it, but provides no selection guidance, prerequisites, 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?

No annotations provided, so description carries full burden. It states 'create' (write operation) and 'Returns: Created CLI template group', but does not disclose potential side effects, error handling, or whether the operation is idempotent. Limited transparency for a mutable action.

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

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

Description is very short and frontloaded with the purpose. The use of 'Args:' and 'Returns:' provides a clean structure. However, it could be slightly more structured (e.g., bullet points) but is already efficient.

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

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

Simple creation tool with output schema available, so description covers basic purpose and parameters. However, it lacks context about prerequisites (e.g., does the ADOM need to exist?) and behavior on conflicts. Adequate 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?

Schema coverage is 0%, and the description provides basic mappings for each parameter (e.g., 'adom: ADOM name'). This adds some meaning beyond the raw schema, but lacks examples, constraints, or context about valid values, making it minimally helpful.

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

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

The description clearly states 'Create a new CLI template group' with a specific verb and resource. The name itself distinguishes it from sibling create tools for other entities like packages or scripts, making 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?

No explicit guidance on when to use this tool versus alternatives. The name implies its purpose, but there is no mention of prerequisites or exclusions. Usage is implied but not elaborated.

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

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

With no annotations, the description carries the full burden. It usefully discloses FortiOS defaulting behavior for default_gateway (interface address), dns_servers (system dns-service), and vdom ('root'), which the schema cannot convey. However it does not say whether the change is staged in the device DB and requires commit_adom/install to take effect, whether re-creating an overlapping scope errors, or what permissions are required.

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

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

Purpose is front-loaded in one sentence, then a scannable args list where each line earns its place. The Returns line is slightly redundant given an output schema exists, and the wrapped default_gateway/dns_servers lines are a bit verbose, but nothing is 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 9-parameter mutation tool with no annotations, the description covers purpose, all parameters, defaults, and return shape (with an output schema backing it). The remaining gap is deployment semantics — whether a commit/install step is needed for the scope to become active — which matters for a device DB write.

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 do all the work, and it does: every one of the 9 parameters is explained with meaning, an example value ('vlan15', '255.255.255.0'), a cardinality limit (up to three DNS servers), a unit (lease time in seconds), and defaults. This is substantially more than the bare titles in the schema.

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

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

The opening line gives a specific verb+resource+scope: 'Create a DHCP server scope in a device's device DB.' That distinguishes it from the many other create_* siblings (interfaces, VAPs, IPsec phases). It stops short of naming the sibling it complements (update_device_dhcp_server / list_device_dhcp_servers) or the precondition that the device already be managed.

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 by the verb and the parameter set, and one behavioral hint is given for default_gateway ('per FortiOS behavior'). But there is no explicit when-to-use/when-not, no statement of prerequisites (device must exist in the ADOM/VDOM), and no mention of the list_device_dhcp_servers alternative for checking existing scopes.

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

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

No annotations exist, so the description carries the full load; it does well to disclose that this writes only to the dvmdb and doesn't touch live devices, plus the default os_type='unknown'. It omits risks an agent needs: behavior when the group name already exists, whether an ADOM lock is required (lock_adom is a sibling), and permission 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?

Front-loaded with the purpose and safety scope, then systematically covers args, returns, and an example. The long os_type enumeration is bulky but earns its place because the schema declares no enum; the Returns block is mildly redundant given an output schema exists.

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 4-parameter mutation tool with no annotations, it supplies purpose, scope, all parameter semantics, return shape, and a worked example. The remaining gap is edge-case behavior (duplicate name handling, ADOM lock expectations) which an agent would want before calling.

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%, yet the description defines all four parameters, including the meaning of adom and name as the group master key, the default for os_type, and the full 33-value os_type enumeration that is absent from the schema. That is meaningful compensation well beyond the structured fields.

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?

Opens with a specific verb+resource ('Create a device group in FortiManager's device manager database') and immediately scopes it as a dvmdb metadata object that does not touch live devices. That scope statement separates it from siblings like add_device_to_group or execute_script_on_device_group without the agent opening a 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 context for why groups exist ('bulk operations like policy installation') and clarifies the operation is metadata-only, which implies when to reach for it. However, it never names the complementary siblings (add_device_to_group, add_group_to_group, add_devices_to_group_bulk) or states prerequisites, so the agent must infer the boundary between creating a group and populating one.

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

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

With no annotations, the description carries the full burden and does disclose the most important non-obvious behavior: the change lands in the device DB and requires a separate preview/install push to reach the FortiGate. It omits secondary traits: whether an ADOM lock is needed, whether duplicate names or vlanids error, idempotency, and permission 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?

Front-loaded with the core action and workflow routing, then a clean Args/Returns block proportionate to ten parameters. The only waste is 'Returns: Creation result,' which adds nothing given an output schema exists.

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 ten-parameter mutation tool with zero annotation coverage, the description covers action, staging-vs-live semantics, follow-up calls, and every parameter's format. An output schema means return values need no prose. Remaining gap is operational preconditions (ADOM lock, permissions, duplicate handling) that an agent would otherwise have to discover by failing.

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 fully compensates with an Args block that documents all ten parameters, including formats the schema does not encode: vlanid range 1-4094, ip as CIDR or 'address netmask', a concrete allowaccess example, and the role value set lan/wan/dmz/undefined.

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

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

States a specific verb, resource, and scope: create a VLAN subinterface in a device's device DB. The 'VLAN subinterface' qualifier narrows it usefully against siblings like create_device_vap, update_device_interface, and delete_device_interface, and the same sentence establishes that this writes to the staging DB rather than the live FortiGate.

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

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

Explicitly places the tool in a workflow chain: read back with get_device_interface_config, then push with preview_install + install_device_settings. That tells an agent both what to do next and that this call alone does not reach the device. It stops short of naming exclusions, e.g. that modifying an existing interface requires update_device_interface rather than this create.

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

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

With no annotations, the description carries the load and does so well: it discloses that this is a write into the device DB, that the peertype default is a live-verified workaround for an FMG 7.6.7 'peer invalid value' rejection, that proposal/dhgrp are passed through largely unvalidated, and that echoed credentials are stripped from the result. It does not mention ADOM locking or that a commit/install is required for the change to take 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?

The opening sentence front-loads purpose and scope before the argument list, and the Args block is scannable with no filler entries. The peertype paragraph is longer than strictly needed and could be compressed, but the extra length buys real behavioral information rather than repetition.

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

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

For a 16-parameter mutation tool with zero schema descriptions, the description supplies the enum values, defaults, conditional requirements and validation caveats an agent needs to construct a valid call. Return values need not be explained since an output schema exists. The missing piece is lifecycle context — ADOM lock/commit expectations after creating the object.

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%, yet the description documents essentially every one of the 16 parameters: enumerations for type, ike_version, mode, peertype, nattraversal, dpd; the 6-128 character constraint on psksecret; the conditional requirement that remote_gw be set when type is static; and the note that mode is ignored on IKEv2. This more than compensates for the empty 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?

States a specific verb and resource ('Create an IPsec phase1-interface (remote gateway / IKE SA) in a device's device DB') and explicitly disambiguates from the legacy policy-based 'phase1' table, which is exactly the confusion an agent would have. It also situates the object relative to the sibling phase2-interface 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 scope constraint 'Route-based (interface-mode) tunnel only' tells the agent when this tool is the right choice versus the legacy policy-based path, and the 'interface' arg is defined as the outgoing local interface. There is no explicit pointer to follow-up calls (e.g. creating the phase2 child or committing the ADOM), so it stops just short of full when/how guidance.

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

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

With no annotations, the description carries the full behavioral burden; it usefully discloses that omitting src_subnet/dst_subnet yields the FortiOS 0.0.0.0/0 default (a meaningful security gotcha) and that proposal/dhgrp are pass-through. But it says nothing about permissions, ADOM/device locking, commit requirements, duplicate-name handling, or idempotency for a mutation tool.

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

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

Front-loaded one-sentence purpose followed by a well-structured arg list where each entry adds real information rather than restating the schema title. The trailing 'Returns: Creation result' is near-zero content and a small amount of trailing padding exists.

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?

A 14-parameter write tool with zero annotation coverage and no output-schema burden on the description (an output schema exists, so return-value detail is rightly omitted). Given that this is a network-config mutation, the absence of lock/commit/permission/conflict behavior leaves the description short of complete.

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

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

Schema coverage is 0%, so the Args block does the heavy lifting and largely succeeds: accepted CIDR vs 'address netmask' forms with an example for src_subnet, allow/deny value sets for pfs/replay/keepalive/auto_negotiate, the 120-172800 range for keylifeseconds, and the 'root' default for vdom. The two deferred params ('pass-through, see module docstring' for proposal and dhgrp) remain unexplained since that docstring isn't available 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?

States a specific verb and resource with clarifying gloss ('IPsec phase2-interface (tunnel/traffic selector)') and scopes it to 'a device's device DB'. It implicitly separates from create_device_ipsec_phase1_interface by naming phase1name as the parent, though it never explicitly contrasts with update_/delete_ phase2 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?

Usage is implied rather than stated: phase1name's description signals the phase1-interface must already exist as a prerequisite, and the omitted-parameter defaults tell the agent what happens when optional args are skipped. There is no explicit when-to-use versus update_device_ipsec_phase2_interface, nor any note on lock/commit prerequisites before the change takes effect.

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

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

With no annotations, the description carries the full behavioral burden and does well by disclosing that this only stages the FortiOS configuration object and does not trigger or retrieve packets. It does not cover mutation edge cases such as duplicate names, permission requirements, or whether a commit is 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?

The description is front-loaded with the core action and distinction from the sibling tool, then gives a useful scope caveat and parameter semantics. It is somewhat long, but the length is justified by the complex FortiOS distinction and the 0% schema description coverage.

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 nine parameters, zero schema descriptions, and an output schema, the description provides everything needed to call the tool correctly. It explains all parameters, the tool's scope boundary, and its relationship to the persistent sniffer alternative.

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 all nine parameters. It provides meaningful semantics for each: device, name, interface, max_packet_count default, IPv4/IPv6 hosts, port range, IANA protocol range, capture_non_ip default, and vdom default.

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: creating a bounded on-demand packet sniffer on a managed device. It explicitly distinguishes this from create_device_sniffer by explaining the name-keyed, bounded one-shot nature versus the id-keyed persistent sniffer.

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 tells the agent when this tool is appropriate versus create_device_sniffer and clarifies that triggering the capture or retrieving packets is out of scope. This prevents the agent from expecting the tool to start a live capture, which is handled elsewhere.

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