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 additive semantics, that duplicate member names are skipped (idempotent behavior), and what the response reports. It omits permission requirements and what happens if a named address object does not exist, which matters 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 with purpose, then a use case, then labeled Parameters/Returns sections. The parameter list largely restates the schema, a small redundancy, but the overall length is tight and every other line carries information.

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

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

For a 4-parameter mutation tool with no annotations and no output schema, the description covers add-vs-replace semantics, duplicate handling, and return contents. Missing failure modes (nonexistent member objects, invalid group name, device/vdom mismatch) keep 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 100%, so the baseline is 3; the description earns an extra point by adding the 'already-present names are skipped' semantics for members and noting that vdom is optional. It adds no format or constraint details beyond that.

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 (add), resource (address objects), target (existing address group) and a critical scope constraint (keeping current members). This cleanly distinguishes it from remove_address_group_members and create_address_group in the sibling list.

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

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

The 'Typical use' paragraph gives a concrete scenario (exempting a new host that a policy already governs) and implicitly steers the agent away from editing the policy directly. It stops short of explicitly naming the alternative tools (e.g. remove_address_group_members, update_firewall_policy) or stating 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?

With no annotations provided, the description carries the full behavioral burden. It usefully discloses authentication options, the preferred API-token method, defaults, and a brief return summary, but it omits important mutation behavior such as persistence, duplicate device_id handling, permission requirements, and 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 opening sentence is front-loaded and clear. However, the parameter list largely duplicates the fully described input schema, so much of the text does not add new information; the returns section is useful because there is no output schema.

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 purpose, all 9 parameters with defaults, authentication choices, and a basic return summary. Since there is no output schema, the returns note is helpful. The main remaining gap is mutation behavior and error/duplicate handling, but overall it is fairly 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 already 100%, so the baseline is 3. The description adds value by explaining that username/password apply only when not using an API token, and that api_token is the preferred authentication method, which is not captured in the schema alone.

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: adding a new FortiGate device to the MCP server. It is clearly distinguishable from sibling tools such as remove_device and list_devices, 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 explains what the tool does but gives no explicit guidance on when to use it versus alternatives like test_device_connection or discover_vdoms. It also does not state prerequisites or the conditions under which this registration tool should be selected.

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 mostly does: it discloses that the write target is the MCP host filesystem, that overwrite defaults to false (so an existing file causes failure unless opted in), and that the parent directory must already exist. It omits permission/API-scope requirements and failure behavior, so not a 5.

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

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

Front-loaded one-sentence purpose followed by compact parameter and return lists — easy to scan. The parameter section largely duplicates a schema that is already fully documented, so a small amount of text doesn't earn its place.

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

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

There is no output schema, and the description compensates by describing the return payload (saved path, size, line count). For a tool with a host-side write side effect and no annotations, the main remaining gap is error/partial-failure behavior and whether the device config is fetched over the already-configured credentials.

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

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

Schema coverage is 100%, so the baseline would be 3; the description goes beyond the schema by explaining the global-vs-vdom dichotomy in the scope parameter, tying vdom to that choice, and adding the parent-directory constraint on output_path. Most other parameter text is a restatement of the schema.

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

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

States a specific verb (download/save) and resource (running configuration) plus the destination (a file on the MCP server host), which is the detail an agent most needs. It is unmistakably distinct from every sibling, which are read/list/monitor tools that never touch the host filesystem.

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?

Implied usage is clear (produce a configuration backup file), and the 'parent directory must exist' note hints at a prerequisite, but it never states when to use this versus surfacing config via cmdb_get/get_system_global, nor any connectivity or permission preconditions. No exclusions are given.

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

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

No annotations are provided, so the description carries the full burden. It does disclose two useful traits: the underlying GET endpoint (implying read-only) and that secret fields are redacted in the response. It omits permission requirements, behavior for missing keys, and vdom resolution, so it is only partially transparent.

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

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

Endpoint is front-loaded, examples follow, and the parameter/return lists are short. The parameter bullets largely restate the schema descriptions, which is slightly 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 4-parameter read tool with no output schema, the description covers the essentials: what is fetched, valid path/key shapes, vdom as optional, and that the response is raw JSON with secrets redacted. Only edge-case behavior (unknown key, vdom default) is missing.

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

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

Schema coverage is already 100%, so baseline is 3, but the description earns above that by explaining what a key looks like ('policy id, object name, interface name, ...') and giving real path/key pairs that show the relationship between the two parameters.

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

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

States a specific verb ('Get') and resource ('one configuration object by key') and pins the exact REST endpoint GET /api/v2/cmdb/{path}/{key}. The concrete path/key examples make the scope unambiguous; it differs from cmdb_list by being single-object retrieval, though it does not name that sibling explicitly.

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

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

The three worked examples (firewall/policy, system/interface, vpn.ipsec/phase1-interface) imply when the tool is applicable and show valid path shapes, but there is no explicit statement of when to use cmdb_get instead of cmdb_list or the specialized list_*/get_*_detail 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?

With no annotations, the description carries the behavioral burden and does disclose that this is a GET/read operation, that secret-looking fields are redacted, and that large responses are truncated. It does not discuss authentication/permissions or error behavior, so it falls short of fully comprehensive disclosure.

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

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

The description is front-loaded with purpose and escape-hatch role, then caveats, parameters, and returns. The parameter list repeats schema names but earns its place by adding examples and syntax, and there is no filler.

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

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

For a 7-parameter generic read tool with no annotations or output schema, the description explains read semantics, redaction/truncation, parameter narrowing, and that the return is raw JSON with results plus metadata. The exact response envelope remains lightly specified, which leaves a small gap without an output schema.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds useful meaning beyond the schema: path examples, filter syntax such as 'status==enable' and 'name=@vlan' with '&' joining, and a pipe-separated format_fields example. This materially improves parameter usage guidance.

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

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

States a specific verb and resource: list every object of any FortiOS configuration table, including the underlying endpoint GET /api/v2/cmdb/{path}. It explicitly positions itself as the escape hatch for tables without a dedicated tool, which distinguishes it from cmdb_get and the many dedicated list_* siblings.

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

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

The phrase 'escape hatch for tables that have no dedicated tool' gives clear when-to-use and when-not-to-use guidance, with the alternative being the dedicated tool class. It also tells the agent to narrow large responses with filter_expr, count, or format_fields, and gives concrete path examples.

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 present, the description carries the full behavioral burden. It does disclose a real constraint (members must be existing address object names) and that a creation status is returned, but it says nothing about duplicate-name behavior, permissions, or whether creation is atomic when a member name is invalid.

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 purpose sentence followed by a compact parameter list and a one-line return note. The parameter list partly restates the schema, but it is short and carries the added format and minimum-count details, so it earns its space.

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

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

For a five-parameter mutation tool with no annotations and no output schema, the description covers the inputs and gestures at the return value, but omits failure modes and the vdom/device context needed when creating objects on a multi-VDOM FortiGate.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds value beyond the schema: it specifies the allowed character set for name (letters, digits, underscore, hyphen) and states that members requires at least one entry, which the schema's array type alone does not convey.

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 plus the source of the data: 'Create a new address group from existing address object names.' An agent can tell this apart from list_address_groups or update_address_object, though it doesn't explicitly name the sibling group-modification 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?

Usage is only implied by the verb 'Create'; the description never says to use this instead of add_address_group_members when the group already exists, nor does it state prerequisites such as the device being registered or the member objects already existing on that device.

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 discloses that this is a create operation and summarizes return values, but it does not cover permissions, duplicate-name behavior, or failure modes 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 front-loaded and organized into purpose, parameters, address_data guidance, and returns. It is efficient, though it repeats some schema parameter names and could be slightly tighter.

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

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

For a create tool with no output schema and no annotations, it covers purpose, required inputs, optional vdom behavior, address_data fields, and expected returns. It still omits duplicate handling and permission requirements, which would fully round out the behavioral context.

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

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

Top-level parameter descriptions already have 100% schema coverage, establishing a baseline of 3. The description adds meaningful semantics for the nested address_data object by listing supported fields and their purposes, which the schema leaves generic via additionalProperties.

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

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

The description states a specific verb and resource: create a new address object on a FortiGate device. It also clarifies the object's role in firewall policies, distinguishing it from sibling operations like list, update, and delete address objects.

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 frames the tool as adding a new network address object usable in security rules, which gives an agent a clear use context. It does not explicitly say when to use update_address_object instead or how to handle existing objects, so it lacks exclusion guidance.

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

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

With no annotations, the description carries the full disclosure burden. It does communicate that this is a raw, schema-unvalidated POST across arbitrary tables and that the response reports creation status and possibly the new object's key — useful context. It stops short of stating auth/permission requirements, what happens on duplicate names or invalid FortiOS fields, or whether vdom scoping changes 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?

Front-loaded with the action and endpoint, then usage routing, then parameters, then returns — a clean structure with no filler prose. The per-parameter bullets largely restate schema descriptions, which is the only redundancy; the usage examples and payload example are the highest-value sentences and come first.

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

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

For a generic mutation tool with no annotations and no output schema, this covers purpose, selection rule, payload conventions, and return behavior — enough for an agent to invoke it correctly. The remaining gap is failure-mode and permission context, which a generic create tool arguably should state given how much blast radius 'any table' implies.

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

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

Schema description coverage is 100%, so the baseline is 3. The description earns the bump by adding a concrete payload shape example ({"name": "...", "member": [{"name": "..."}]}) that illustrates the nested-array convention for FortiOS data, which the schema only hints at with 'Object payload (FortiOS field 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?

States a specific verb and resource (create a configuration object in any CMDB table) and pins down the mechanism (raw JSON POST /api/v2/cmdb/{path}). It also distinguishes itself from the typed create_* siblings in the same breath, so an agent can tell immediately which family of tools this belongs to.

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

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

Gives an explicit selection rule: use the typed create_* tool when one exists, and this tool for tables that lack one. Concrete example paths (firewall/ippool, system/zone, vpn.ipsec/phase2-interface) make the exclusion condition operational rather than abstract.

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 is a write operation, explains the DHCP server selection precedence, and states duplicate IP or MAC reservations are rejected before anything is written. It does not mention permissions, reversibility, or side effects on existing leases, which prevents a 5.

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

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

The description is front-loaded with the core action, followed by a structured parameter list and a short returns section. The selection precedence and duplicate-rejection rule are included without rambling or repetition; no sentence feels extraneous.

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

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

There is no output schema, but the description includes a brief Returns section noting creation status and the chosen DHCP server, which is useful. Combined with the parameter explanations and server-selection logic, it is nearly complete, though it could clarify permissions or what happens if server selection fails.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds meaningful semantics beyond the schema by defining the precedence between dhcp_server_id, interface, and automatic subnet-based selection. It also references list_dhcp_servers for obtaining server IDs, which helps the agent populate the parameter correctly.

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

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

The description uses a specific verb and resource: 'Reserve an IP address for a MAC address on a FortiGate DHCP server.' It clearly distinguishes this creation action from siblings such as delete_dhcp_reservation and list_dhcp_servers without requiring schema inspection.

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 explains how the target DHCP server is selected by dhcp_server_id, then interface, then subnet containment, and references list_dhcp_servers for server IDs. It provides clear operating context but does not explicitly state when to avoid this tool in favor of alternatives or what prerequisites are required.

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

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

With no annotations, the description carries the burden and does disclose useful behavior: vdom falls back to the device default, and the return includes the assigned policy ID and a configuration summary. It does not say whether creation fails on unresolved object references, where the policy lands in the policy order, or what permissions are required for a write operation on FortiGate.

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, then short scoped sections for parameters, policy data, and returns. No filler sentences, though the Parameters block largely restates what the schema already says.

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

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

For a 3-parameter creation tool with no output schema and an opaque nested object, the description supplies the missing payload shape and the return contents, which is exactly what an agent needs to construct a valid call. Remaining gaps (policy ordering, error conditions) are minor for a create operation.

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

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

Schema coverage is nominally 100%, but policy_data is a free-form object with additionalProperties:true and only 'Policy configuration as JSON' as its schema text. The description compensates by enumerating the expected inner keys (name, srcintf, dstintf, srcaddr, dstaddr, service, action), which is substantial value beyond the schema. It does not indicate which of those inner fields are required or how lists vs scalars are handled.

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

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

Clear specific verb + resource: 'Create a new firewall policy on a FortiGate device', followed by a one-line statement of what that means operationally (rules for source, destination, services). It is distinguishable from siblings like update_firewall_policy or move_firewall_policy by name, but the description never explicitly contrasts with them.

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

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

Usage is implied (you need a device_id and a policy_data payload with interface/address/service objects) but the description never states when to use this versus update_firewall_policy, nor that referenced address/service objects should exist first via create_address_object/create_service_object. No exclusions or prerequisites are given.

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

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

With no annotations, the description must carry the full behavioral burden. It does disclose that this is a write operation and summarizes the return payload (creation status plus configuration summary), but it says nothing about duplicate-name behavior, whether the object is committed immediately, permission requirements, or failure modes.

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 the purpose and the remaining sections are scannable lists. The "Parameters" block partially duplicates the input schema, which is mild waste, but the Returns section earns its space since no 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?

The enumerated nested fields and the returns summary compensate well for the absent output schema and untyped nested object. However, for an unannotated mutation tool it omits the safety profile (reversibility, error handling) and the preconditions an agent needs before invoking it.

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

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

Schema coverage is 100%, so the baseline is 3, but the description earns a step up by enumerating the nested service_data fields (name, protocol, tcp-portrange, udp-portrange, comment) — the schema declares service_data only as an open object with no field-level detail. It also restates that vdom is optional and falls back to the device 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 opens with a specific verb and resource ("Create a new service object on a FortiGate device") and adds scope detail: it defines protocols and ports for use in firewall policies. That distinguishes it implicitly from update_service_object, delete_service_object, and list_service_objects, though those siblings are never named.

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 only implied by the phrase "for use in firewall policies." There is no explicit when-to-use guidance, no mention of the update_service_object alternative for modifying existing objects, and no stated prerequisite that the device must already be registered (add_device) or the VDOM must exist.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the shape of the mutation (routing entries, optional vdom fallback) and a coarse return summary, but says nothing about permissions, duplicate-route handling, validation failures, or whether the change is immediate/committed. For a config-writing tool with zero annotation coverage this is a real gap.

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-line summary, then Parameters, nested Route data, and Returns in labeled blocks. Sentences are short and each block maps to something an agent needs; the definitional sentence about forwarding traffic is the only mild 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?

Covers inputs, nested route fields and a rough return shape, which is reasonable for a 3-param tool with no output schema. However, with no annotations and no output schema, an agent still lacks failure-mode and side-effect information (does a duplicate destination error or overwrite?) that matters for a routing-mutation 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 nominally 100%, but the key parameter route_data is an untyped nested object (additionalProperties: true) with no field documentation in the schema. The description compensates by enumerating dst, gateway, device, distance and comment, which is genuinely necessary information. It does not state which of those nested fields are mandatory, capping 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?

Specific verb+resource ('Create a new static route on a FortiGate device') plus one sentence of semantic context about what a static route does. It is distinguishable from list_static_routes / update_static_route / delete_static_route by verb, but the description never explicitly names or contrasts those 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 only implied by the word 'new' — an agent can infer this is for adding routes that do not yet exist, and must look elsewhere for modification or removal. No exclusions (e.g. 'use update_static_route for existing routes'), no prerequisites, no note about VDOM selection rules beyond 'uses device default'.

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 states that a new object is added and lists basic returns, but does not disclose permission/auth requirements, duplicate-name behavior, dependency constraints, idempotency, or whether creation is reversible.

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

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

The description is front-loaded with purpose and usage, then uses a structured parameter list and returns section. It is readable, but the parameter list largely repeats schema descriptions that already have 100% 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?

It covers purpose, use cases, all parameters, defaults, and a basic return summary, which is enough to attempt invocation. However, for a mutation tool with no annotations and no output schema, it does not address prerequisites, authorization, or failure modes.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds some meaning beyond the schema by naming protocol values (tcp/udp), stating that portforward defaults to disable, and noting extport, mappedport, and vdom as optional, though it does not detail IP/port formats or parameter interdependencies.

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

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

States a specific verb 'Create' and resource 'Virtual IP' on a FortiGate device, and explains the object's role in port forwarding, NAT, and external access. It is clear but does not explicitly differentiate itself from sibling list/update/delete virtual IP 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?

Offers use cases for the created object, which implies when to use the tool, but gives no explicit when-to-use guidance versus alternatives such as update_virtual_ip, list_virtual_ips, or create_firewall_policy. It also omits prerequisites like device reachability or interface existence.

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 burden. It does disclose a genuine behavioral trait beyond the schema — referential-integrity enforcement that will cause the call to fail — plus a return value. However, for a destructive operation it omits irreversibility, required permissions, and what happens to group members on deletion.

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 action and its key constraint, then short parameter and return sections. The parameter list largely duplicates the schema, which is the only wasted space.

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

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

For a destructive, non-annotated tool with no output schema, the definition should say more: whether deletion is irreversible, whether dependent references must be removed first by the agent, and what the deletion status actually contains. The referential-integrity note is the only substantive behavioral content.

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

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

Schema description coverage is 100%, so the schema already documents device_id, name, and vdom. The description's parameter list restates those same glosses without adding format, examples, or vdom-defaulting behavior, so baseline 3 applies.

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

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

States a specific verb and resource ("Delete an address group"), which cleanly separates it from the create/update/list address-group siblings and from delete_address_object or delete_service_object. It doesn't explicitly contrast with those siblings, but the resource noun carries the distinction.

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

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

The note that FortiOS refuses while a policy still references the group gives a real precondition an agent should check (e.g., via list_firewall_policies or lookup_policy), but usage is implied rather than stated as explicit when-to-use/when-not guidance or an alternative path.

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

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

With no annotations, the description carries the full burden, and it does disclose one valuable trait: reference-blocking by policies/groups. It omits other behavioral facts an agent needs for a destructive operation, such as irreversibility, required permissions, and whether dependent objects are cascaded or orphaned.

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 failure condition is front-loaded in the first sentence, and the parameter/return lists are terse. Some space is spent restating schema text, which is mild waste but not bloat.

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

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

For a simple three-parameter delete tool with no annotations and no output schema, the description covers the operation, inputs, key failure mode, and a bare return value ('Deletion status'). The return value's shape is vague and irreversible-deletion semantics are unstated, keeping it below a 5.

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

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

Schema description coverage is 100%, so all three parameters are already documented; the description's parameter list is largely a restatement ('Identifier of the FortiGate device' vs the schema's 'FortiGate device identifier'). It adds no format, scoping, or VDOM-selection guidance beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Delete an address object'), which cleanly distinguishes it from delete_service_object and delete_address_group in the sibling list. An agent can pick it out without opening the schema.

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

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

The line 'FortiOS refuses while a policy or group still references it' gives a concrete precondition for failure, which effectively tells the agent when this call will not succeed. It stops short of naming alternatives (e.g. remove_address_group_members, delete_firewall_policy) that would resolve that state.

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 key behavioral constraint that FortiOS refuses deletion when the object is still referenced elsewhere. However, it omits other critical traits for a destructive operation: whether deletion is irreversible, what permissions or device connectivity are required, and what failure responses look like beyond the reference constraint.

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, front-loads the operation and endpoint, and uses a clear parameter/return structure. The parameter list is somewhat redundant given the fully documented schema, which keeps it from a 5.

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

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

For a destructive tool with no annotations and no output schema, the description covers the core operation, the endpoint, and one important constraint. It is not complete enough: it says only 'Deletion status' as the return and lacks irreversibility, permission, and broader failure-mode context that an agent needs before invoking a delete.

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

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

Schema coverage is 100% and the description's parameter list largely restates the schema field descriptions (device_id, path, key, vdom) without adding syntax, format, or constraints. The schema already documents vdom as optional with a null default, so the description adds little beyond baseline.

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

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

The description states a specific verb and resource ('Delete a configuration object') and names the REST endpoint DELETE /api/v2/cmdb/{path}/{key}, making the operation unambiguous. It does not differentiate the generic tool from sibling-specific deletes such as delete_service_object or delete_address_object, which an agent might reasonably confuse.

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 by 'from any table' and the name; there is no explicit statement of when to choose this generic delete over specific delete tools. The note that FortiOS refuses deletion while the object is still referenced gives useful context but is a behavioral constraint rather than usage 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 exist, so the description carries the full load. It does disclose a genuinely useful safety trait — ambiguous matches are refused rather than guessed — and names the return value ('Deletion status'). It says nothing about irreversibility, required permissions, or what happens to the lease when a reservation is removed, which matters for an unannotated destructive 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 purpose is front-loaded in one sentence, and the parameter/return blocks are scannable. Much of the parameter list duplicates schema text at 100% coverage, which is mildly wasteful but keeps the description self-contained.

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 6-parameter destructive tool with no annotations and no output schema, the description covers the essentials (target identity, ambiguity refusal, return signal). It leaves gaps on selector precedence, vdom behavior, and permission/irreversibility, so an agent could still mis-invoke it by passing conflicting identifiers.

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

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

Schema description coverage is 100%, so the baseline applies. The description adds only marginal value beyond the schema: it marks reservation_id as coming from list_dhcp_servers and explains dhcp_server_id as a search narrower. It does not explain selector interaction or the role of vdom.

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

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

The first sentence gives a specific verb (Delete) and resource (DHCP reservation) plus the identifier set (reservation_id, ip, mac), which clearly separates it from create_dhcp_reservation and the list_* siblings. It stops short of naming an alternative tool to use when the target is uncertain, but the purpose itself is unambiguous.

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

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

Usage is implied by 'identified by reservation_id, ip or mac' and by dhcp_server_id being described as narrowing the search, plus the parenthetical '(see list_dhcp_servers)' hinting at how to discover IDs. There is no explicit when-to-use / when-not-use statement and no guidance on whether selectors can be combined or which takes precedence.

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 does disclose that deletion is permanent and that it modifies device configuration. It omits permission/auth requirements, dependency or referential-integrity effects, whether the change is committed immediately to the FortiGate, and confirmation/rollback 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?

Front-loaded with the core action, then short sections for parameters and returns. The second sentence ("removes an existing firewall policy... permanently deleting the specified security rule") largely repeats the first, and the parameter list duplicates the schema.

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?

No output schema exists, so the "Returns: Deletion status confirmation" line usefully fills that gap. However, for a destructive, annotation-free mutation tool the description leaves out device reachability expectations, VDOM scoping implications, and failure modes, which an agent would need.

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

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

Schema coverage is 100%, so the schema already documents device_id, policy_id and vdom, making 3 the baseline. The description restates the parameters nearly verbatim, adding only that omitting vdom falls back to the device 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?

States a specific verb and resource ("Delete a firewall policy from a FortiGate device"), which cleanly separates it from create_firewall_policy, update_firewall_policy, move_firewall_policy and list_firewall_policies. It does not explicitly name those siblings or explain the difference, so it stops short of a 5.

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

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

No guidance on when to use this versus alternatives, no prerequisites (e.g., whether the policy must be unused or detached from references), and no warning about mitigations such as backup_config before deleting. The only hint that it is destructive is the word "permanently" in the body.

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 does disclose the non-obvious referential-integrity rejection, which is genuine behavioral value, but omits that deletion is irreversible, whether permission/scoping is required, whether vdom defaults, and how a not-found object is reported. Adequate but materially incomplete for a destructive operation.

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

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

Two-sentence summary followed by compact Parameters/Returns blocks; the blocking condition is front-loaded where it matters most. Slight redundancy with the schema in the parameter list, but nothing is padded.

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

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

The "Returns: Deletion status" note partially compensates for the absence of an output schema, and the three parameters are simple. But without annotations, the description should still cover irreversibility and failure modes beyond the reference check, which it does not.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description's parameter list restates those labels nearly verbatim and adds little beyond marking vdom as optional. Baseline 3 is correct here.

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

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

States a specific verb and resource ("Delete a custom service object"), which cleanly distinguishes it from delete_address_object and from update_service_object/create_service_object in the sibling set. It does not explicitly name an alternative, but the resource is unambiguous.

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

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

Adds a concrete precondition: FortiOS refuses deletion while a policy or service group references the object. That tells the agent the operation can fail for reasons outside its control and that cleanup elsewhere may be needed first. It stops short of naming the follow-up tools (e.g. list_service_groups, policy lookups) or stating what to do on refusal.

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, and it discloses only that configuration is mutated. It says nothing about whether deletion is irreversible, what happens if the route_id does not exist, required permissions, or whether the change takes effect immediately in the routing table. Only the "Returns: Deletion status confirmation" line adds any behavioral context.

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

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

The purpose is front-loaded in the first sentence, followed by a clarifying sentence and compact parameter/return lists. The parameter list largely duplicates the schema, which is mild waste, but the description stays short and scannable.

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

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

For a three-parameter destructive tool with no annotations and no output schema, the description covers the basic contract and states the return value. It stops short of the details an agent most needs before a delete: irreversibility, permission requirements, and failure behavior when the route does not exist.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema, making 3 the baseline. The description adds one piece of meaning beyond the schema by noting that vdom is optional and falls back to the device default, but device_id and route_id are merely restated.

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 (delete) and resource (static route) scoped to a FortiGate device, so the agent knows exactly what is being removed. It does not differentiate from siblings such as update_static_route or get_static_route_detail, but the verb/resource pairing is unambiguous on its own.

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?

"Removes an existing static route" implies the precondition that the route must already exist, which is the only usage signal. There is no explicit guidance on when to choose this versus update_static_route, no prerequisite checks (e.g. confirm via get_static_route_detail first), and no stated exclusions or warnings about removing an in-use route.

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 the tool removes an existing object from device configuration, that in-use Virtual IPs cannot be deleted, and that it returns a deletion status confirmation, but it omits permission requirements, failure behavior, and whether deletion is immediate or reversible.

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

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

The description is structured with clear sections and front-loads the main action. However, the first two sentences substantially repeat the same point, and the Parameters section duplicates schema descriptions that are already at 100% coverage, reducing efficiency.

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

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

The description covers the core action, the main deletion constraint, and the return confirmation, which is important because no output schema exists. Still, for a destructive tool with no annotations, it should ideally say more about required permissions, error cases, and reversibility to be 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 coverage is 100%, so the schema already documents all parameters, which sets a baseline of 3. The description adds some value beyond the schema by clarifying that vdom is optional and uses the device default, making the parameter behavior easier to apply correctly.

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

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

The description states a specific verb and resource: deleting a Virtual IP from a FortiGate device, and clarifies it removes an existing Virtual IP object from the configuration. This distinguishes it from sibling Virtual IP tools such as list_virtual_ips, create_virtual_ip, update_virtual_ip, and get_virtual_ip_detail.

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

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

The description implies use when removing an existing Virtual IP and includes one useful when-not condition: Virtual IPs in use by policies cannot be deleted. However, it does not explicitly compare this tool with alternatives such as update_virtual_ip or explain prerequisites for successful deletion.

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 conveys the read-only nature ('queries', 'retrieve') and what comes back (status, resource allocation), but omits error behavior when the device is unreachable/unknown device_id, auth requirements, and explicit confirmation that nothing is modified.

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-line purpose, followed by compact Parameters and Returns sections. The Returns breakdown is genuinely useful because no output schema exists; no filler 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?

No output schema, so the description appropriately enumerates the returned data (VDOM configuration, enabled/disabled status, resource allocation). With a single parameter and no annotations, the only meaningful gap is failure behavior for invalid or unreachable devices.

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

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

Schema coverage is 100% and the single parameter is already documented in the schema. The description restates its meaning ('Identifier of the FortiGate device to query'), which adds the intent of querying without exceeding the schema. Baseline 3 exceeded marginally by clarifying query semantics.

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

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

States a specific verb and resource: 'Discover and list all Virtual Domains (VDOMs) on a FortiGate device.' No sibling tool covers VDOMs, so the target is unambiguous even without an explicit contrast. Slightly redundant ('Discover and list') but clear.

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

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

The description establishes the context (query a specific FortiGate device to enumerate its configured VDOMs) but never says when to prefer this over generic siblings like cmdb_list, nor any prerequisites such as the device first being registered via add_device. Usage is implied rather than prescribed.

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

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

With no annotations, the description carries the burden and does disclose the impactful behavior: tunnel-down interrupts site-to-site traffic and requires writes enabled. Minor gaps remain on idempotency, permissions specifics, and what 'Action status' actually contains.

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 impact/warning sentence followed by organized Parameters and Returns sections. Some repetition of schema field descriptions, but overall efficient and scannable.

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

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

For a 5-param mutation tool with no output schema, the description covers prerequisites, side effects, defaults, and a brief return note. Slightly thin on return detail, but adequate for correct invocation.

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

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

Schema coverage is 100%, but the description adds value beyond it: phase2_name defaults to all selectors of the phase-1, action enumerates up/down, and phase1_name is cross-referenced to discovery tools. That extra semantics justifies above baseline.

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

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

States a specific verb pair (bring up/down) on a specific resource (IPsec tunnel/phase-1) and even names the underlying monitor endpoints. Clearly distinguishable from sibling read tools like list_ipsec_tunnels.

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?

Explains the consequence of down (traffic interruption until renegotiation) and the prerequisite that writes must be enabled, plus points to list_ipsec_phase1 / list_ipsec_tunnels for discovering phase1_name. Lacks an explicit 'when not to use' or alternative-tool exclusion, but context is clear.

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

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

With no annotations provided, the description carries the full burden and does disclose the essential traits: this is a POST, it mutates device state, and it requires write access to be enabled. It also states the return is raw JSON. It stops short of noting reversibility, failure modes, or whether actions can be disruptive to live traffic (e.g., deauth), so a 4 rather than 5.

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

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

Front-loads the operation and endpoint, then examples, then a short parameter list and return note. The trailing parameter bullet list largely duplicates the schema descriptions and could be dropped, but the description remains compact and scannable.

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

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

For a mutation tool with no annotations and no output schema, the definition covers the write prerequisite, the raw-JSON return, and concrete invocation patterns, which is enough to call it correctly. It lacks any note on error responses or side effects of specific actions, leaving a small gap.

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

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

Schema coverage is 100%, so baseline is 3; the description earns above baseline by illustrating what `path` and `data` actually look like in three worked examples, which is genuinely helpful for a free-form path/body API. `device_id` and `vdom` are only restated from the schema, so this isn't a 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?

States a specific verb and resource ("Run a monitor action") plus the underlying endpoint POST /api/v2/monitor/{path}, and enumerates the concrete action classes (tunnel up/down, session close, cache flush, deauth). This clearly distinguishes it from read-only siblings like monitor_get and from the narrower execute_ipsec_tunnel_action.

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

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

Gives concrete when-to-use examples with exact paths and payload shapes, plus the crucial prerequisite that writes must be enabled on the device. It does not, however, explicitly route the agent away from overlapping siblings such as execute_ipsec_tunnel_action or monitor_get, which is the only missing piece for a 5.

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

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

With no annotations, the description carries the full burden. It usefully discloses that the lookup is executed on the device (an external dependency that can fail if the device is unreachable) and names the return content, but it says nothing about behavior for private/unresolvable IPs, error modes, or whether results are cached.

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?

Short and front-loaded, with the core action in the first sentence. The Parameters section is redundant against a fully documented schema, but the Returns section earns its place because no 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 simple 3-parameter read tool with no annotations or output schema, the description covers purpose, inputs, and a rough sketch of return values. Minor gaps remain around prerequisites (device reachability, FortiGuard registration) and behavior for unresolvable addresses.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The Parameters section in the description merely restates those descriptions without adding format, syntax, or VDOM-selection guidance beyond the schema.

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

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

States a specific verb and resource: resolve an IP to FortiGuard geolocation (country) via the FortiGate device. It is clearly distinguishable from siblings like ping_from_device or lookup_route, though it does not explicitly name what it is not.

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

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

Usage is only implied: an agent infers it should call this when it needs the country for an IP address. There is no statement of when to prefer it over alternatives (e.g., list_arp_table, lookup_route) and no exclusions or prerequisites.

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

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

With no annotations, the description does useful work by disclosing the return shape: group metadata plus each member with its resolved value, and that nested groups are listed with their members. However, it never states the read-only nature explicitly, nor what happens when the name does not match (empty result vs error), nor how vdom defaults are applied.

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, then compact Parameters and Returns blocks. The parameter list largely restates the 100%-covered schema, but the Returns section earns its place since there is no output schema.

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?

Because there is no output schema, the Returns section is essential and it covers the important edge case of nested group expansion. The remaining gap is failure behavior for a non-existent group and vdom default semantics, which the schema's default=null partly addresses.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds genuine semantics beyond the schema: 'exact match' for name (the schema only says 'Address group name') and 'optional' for vdom. device_id's meaning matches the schema, so the added value is real but modest.

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

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

The description gives a specific verb and resource ('Show one address group') and adds a differentiator unique to this tool: every member resolved to subnet, range or FQDN. That distinguishes it from the sibling list_address_groups, which merely enumerates groups.

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: 'one address group' plus 'name: exact match' signals this is for inspecting a single known group rather than browsing. There is no explicit when-to-use statement, no mention of list_address_groups for finding the name first, and no exclusions.

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

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

No annotations are supplied, so the description carries the full behavioral burden. 'Show' plus the enumerated contents imply a non-destructive read that returns a config object, which is useful, but it says nothing about permission requirements, what happens if BGP is not configured, or whether the response is a single object or a list.

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

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

A single compact sentence with the resource front-loaded and the returned fields parenthetically scoped. No filler, though it is terse enough to leave obvious gaps rather than covering them efficiently.

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

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

For a simple two-parameter read-only getter with full schema coverage and no output schema, this is close to sufficient: the parenthetical field list effectively stands in for a return-value description. Missing are only error/absent-config behavior and vdom scoping, which are minor for this tool class.

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

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

Schema description coverage is 100%, with both device_id and vdom documented in the schema, so the baseline is 3. The description adds nothing about parameter semantics — neither parameter is referenced, and the meaning of the nullable vdom default is left entirely to the schema.

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

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

States a specific verb ('Show') and resource ('BGP configuration'), and enumerates the contents (AS, router-id, neighbors, networks), so an agent can tell it apart from routing siblings like get_ospf_config or get_routing_table. It stops short of explicitly naming those siblings, but the resource noun is unambiguous.

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

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

There is no guidance on when to call this versus alternatives such as get_routing_table or lookup_route, no mention of prerequisites (a valid device_id), and no note on vdom selection behavior. Usage is only inferable from the tool name.

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

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

No annotations are provided, so the description carries the full behavioral-disclosure burden. The verbs 'Get' and 'retrieves' imply a read-only query, and the return list adds context, but the description does not state side-effect guarantees, permission or authentication requirements, live-device dependency, or error 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 purpose is front-loaded in the first sentence and the parameter/return structure is easy to scan. There is minor redundancy between 'detailed system status' and 'comprehensive system information', and the Returns list partially repeats the second sentence.

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

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

With a simple single-parameter read and no output schema, the description usefully enumerates return fields such as model and serial number, software version and build, hostname, operational status, and VDOM information. It does not cover error or permission behavior, but the core retrieval contract is sufficiently described.

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

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

Schema coverage is 100%, and the only parameter, device_id, is already documented in the schema. The description repeats its meaning ('Identifier of the FortiGate device to query') but adds no format, source, or validation details beyond the schema, so the baseline 3 applies.

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

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

The description uses a specific verb, 'Get', and resource, 'system status information', scoped to a specific FortiGate device. It enumerates hardware details, software version, hostname, and operational status, but does not distinguish this from nearby status/resource siblings such as get_system_resources, get_performance_status, or get_license_status.

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

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

There is no explicit when-to-use or when-not-to-use guidance and no named alternative. The description says what it retrieves but does not tell the agent whether to choose it over get_system_resources, get_performance_status, or get_license_status.

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 burden; 'Show' implies a non-destructive read and the field list signals the response shape, which is useful. However, it does not mention whether a device_id must be reachable, what happens on an unreachable device, or any permission requirement.

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

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

A single front-loaded sentence with the resource first and the returned fields in parentheses. No filler, no redundant restatement of the name.

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

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

For a simple read-only getter with fully documented parameters and no output schema, the description is largely sufficient because it enumerates the returned configuration items. It would be complete with a note on the required device context and any failure behavior.

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

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

Schema description coverage is 100%, with both device_id and vdom documented in the schema, so the baseline is 3. The description adds no parameter-level meaning (e.g., whether vdom defaults to the device's global context) beyond what the schema already supplies.

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 ('Show') and resource ('system DNS configuration') and enumerates the fields returned (primary/secondary servers, domain, DoT/DoH), so an agent knows exactly what it retrieves. It does not explicitly distinguish itself from nearby config getters like get_ntp_settings, but the resource is unambiguous.

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

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

There is no statement of when to call this versus alternatives, nor any prerequisite or exclusion guidance. The read-only nature is only implied by the verb 'Show', leaving the agent to infer usage context entirely.

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

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

No annotations exist, so the description carries the full burden. 'Get' implies a read, but the description does not state what 'detailed information' includes, whether it can fail for missing policies, or what permissions are required. That is a significant gap for an unannotated tool.

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

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

The single sentence is front-loaded and free of filler, which suits a simple retrieval tool. It is arguably too terse rather than wasteful, so it stops short of a 5.

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

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

With no annotations and no output schema, the description is the only source of behavioral detail, yet it never describes the returned detail (NAT, security profiles, counters) or failure modes. For a tool sitting among many firewall-policy siblings, that leaves the agent under-informed.

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

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

Schema description coverage is 100%, so device_id, policy_id, and vdom are already documented in the schema. The description adds no syntax, format, or defaulting details (e.g., how a null vdom is resolved), so the baseline 3 applies.

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

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

The description states a specific verb (get) and resource (firewall policy detail) and implies retrieval of one policy versus the sibling list_firewall_policies. It does not explicitly name the contrast, but the singular 'specific' and 'detail' make the distinction 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?

The description gives no guidance on when to use this instead of list_firewall_policies or lookup_policy, and no prerequisites such as whether a vdom context is needed or whether device_id must come from list_devices. Usage is only implied by the name.

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

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

With no annotations at all, the description carries the full disclosure burden. The verb "Show" implies a read-only, non-destructive operation, which is useful, but the description says nothing about required permissions, whether the settings are returned raw or normalized, or what happens if FortiAnalyzer is unconfigured.

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

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

A single short sentence with zero filler, front-loading the verb and resource. Nothing could usefully be removed.

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

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

This is a simple two-parameter read of a settings object, the input schema is fully described, and no output schema exists to defer to. The description gives enough to invoke it correctly, though it could note that vdom is optional and defaults to the global scope.

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

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

Schema description coverage is 100% for both parameters (vdom and device_id), so the schema already documents them adequately. The description adds no extra semantics such as vdom scoping behavior or what device_id format is expected, which is acceptable at baseline 3.

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

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

States a specific verb ("Show") and resource (FortiAnalyzer logging settings) and even cites the underlying API path (log.fortianalyzer/setting), making the target unambiguous. It does not explicitly distinguish itself from adjacent siblings like get_log_settings or list_syslog_settings, so it stops short of a 5.

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

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

There is no statement of when to use this tool versus get_log_settings, list_syslog_settings, or monitor_get/log_get. The agent must infer from the tool name alone that this is a specific-read of one vendor's logging config rather than a general log settings query.

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 important behaviors: data comes from live session statistics (not stored logs) and results are 'one line per entry with sessions, bytes and bandwidth'. It states default and maximum row counts and which parameters are optional, though it does not note whether the call is read-only-safe or costly on the device.

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 line is front-loaded and the parameter/return lists are scannable. Some content duplicates the schema verbatim, but the structure is efficient and nothing is buried.

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

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

There is no output schema, and the description compensates by describing the return shape (sessions, bytes, bandwidth per row). All six parameters are accounted for, including optionality; the main gap is guidance on choosing this tool over sibling monitoring tools.

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

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

Schema description coverage is 100%, so the schema already documents every parameter and both enums. The description restates the same defaults and enum values (source default, bytes default, count max 200) without adding new semantics such as value formats or interactions between report_by and sort_by, so the baseline 3 applies.

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

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

States a specific verb (get) plus a named resource (FortiView top talkers) and pins the underlying data source (monitor/fortiview/statistics), so an agent knows it is a live analytics view rather than a raw session or log listing. It does not explicitly name sibling alternatives such as list_active_sessions or query_traffic_log, which is the only thing keeping it from a 5.

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

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

Usage is only implied: the mention of 'live session statistics' hints this is for current top-talker analysis, but the description never says when to prefer it over query_traffic_log (historical) or list_active_sessions (per-session detail). No prerequisites or exclusions are given.

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

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

With no annotations, the description carries the full burden. 'Show' implies a read-only operation and the empty-list behavior for standalone units is useful, but it does not explicitly state side effects, permissions, error behavior, or response format.

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

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

Two short sentences, front-loaded with the main purpose and followed by the key edge case. There is no filler or redundancy.

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

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

For a simple read-only status tool with a fully described two-parameter schema and no output schema, the description is largely complete: it lists the key returned statistics and explains the standalone empty-list behavior. A little more detail on VDOM scoping or response shape would make it fully complete.

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

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

Schema description coverage is 100%, so device_id and vdom are already documented in the schema. The description adds no additional parameter meaning, syntax, or scoping behavior beyond what the schema provides, so baseline 3 is appropriate.

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

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

States a specific verb and resource: 'Show HA cluster statistics', and enumerates the relevant data: members, roles, sync state. It also distinguishes the standalone case, making it clearly different from generic status or system-resource tools.

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

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

The description implies when the tool is relevant by naming HA cluster statistics and noting standalone units return an empty list. However, it gives no explicit when-to-use guidance versus alternatives such as get_device_status or get_system_resources.

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 must carry the behavioral burden. It discloses that this is a live retrieval of link state, IP configuration, and related details, but it omits error behavior, permission requirements, and what happens when the interface or VDOM is invalid.

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 purpose and organized into Parameters and Returns sections. The Returns section is useful because no output schema exists, though the parameter list largely duplicates the input schema.

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

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

For a simple read-only status tool with no output schema, the description provides a useful list of return fields and distinguishes the single-interface scope. It is only missing explicit error behavior and guidance on when to prefer alternative status or listing tools.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description repeats the parameter names with brief labels and notes that vdom is optional and uses the device default, but it adds little beyond what the schema already provides.

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

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

States a specific verb and resource ('Get the current status of a specific network interface') and specifies the scope as a single named interface on a FortiGate device. This is clearly distinguishable from sibling tools like list_interfaces, which would return multiple interfaces.

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 by saying it retrieves live status for one named interface, but it does not explicitly say when to use this instead of list_interfaces or list_interface_counters. No alternatives are named and no prerequisites are stated.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose whether the call touches the live device, whether it requires the device to be online, what happens on an unreachable device, or what the response contains beyond the general topic.

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

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

A single front-loaded sentence with no filler. It is efficient but arguably under-specified rather than genuinely concise in a way that earns every word.

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

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

For a two-parameter read tool with no output schema, the description covers the topic but omits what the returned license status looks like (expiry dates, entitlement counts, per-VDOM breakdown) and any device-state prerequisites. Adequate but with clear gaps.

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

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

Schema coverage is 100%, so both device_id and vdom are already documented in the schema. The description adds no meaning about scope (e.g., whether omitting vdom returns all VDOMs), so baseline 3 applies.

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

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

States a specific verb ("Show") and a specific resource ("FortiGuard/FortiCare license and subscription status"), naming the two license families covered. It is unambiguous against siblings, none of which deal with licensing, though it does not explicitly differentiate itself.

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

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

There is no guidance on when to call this versus alternatives, no preconditions (device must be registered/reachable), and no mention of whether it is per-device or per-VDOM. Only the verb "Show" weakly implies a read-only status lookup.

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

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

No annotations are provided, so the description carries the behavioral burden. It implies a read-only 'show' operation and summarizes the return format, but it does not mention permissions, device availability requirements, or other operational constraints.

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

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

The description is front-loaded and efficiently structured, first stating the aggregate purpose and then the parameters and return shape. The parameter section largely repeats the schema, which is slightly redundant, but the text remains tight.

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

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

There is no output schema, but the description provides a useful return summary: one line per log destination with status, server and key options. Combined with fully documented parameters, this is enough for an agent to call the tool, though operational caveats are omitted.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description repeats device_id and vdom meanings without adding format details, examples, or behavior beyond the schema baseline.

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

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

The description states a specific verb and resource: showing where the device sends logs across memory, disk, syslog, FortiAnalyzer and FortiCloud in one view. The 'one view' phrasing implicitly distinguishes it from narrower siblings like list_syslog_settings and get_fortianalyzer_settings, but it does not explicitly name them.

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

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

The consolidated-view framing implies when this tool is useful, but there is no explicit guidance on when to use it instead of the sibling-specific syslog or FortiAnalyzer tools. It also gives no exclusions or prerequisites.

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

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

No annotations are supplied, so the description bears the full burden. 'Show' implies a read-only retrieval and the parenthetical previews the returned content, but nothing is said about permissions, vdom-scoping semantics, or failure behavior when a device is unreachable — meaningful gaps given zero annotation coverage.

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

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

A single front-loaded sentence naming the resource first, then the content. Nothing is redundant and there is no filler.

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

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

With no output schema, the parenthetical enumeration of sync mode, servers, and per-interface server mode effectively previews what comes back, which is the right compensation. Only the vdom scoping behavior and read-only nature remain unstated.

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

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

Schema description coverage is 100%: device_id and vdom are both documented in the schema. The description adds no parameter-level meaning (e.g., how vdom affects the returned config), so the baseline 3 applies.

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

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

States a specific retrieval verb ('Show') and a precisely named resource ('NTP configuration') with parenthetical detail on what it contains, which distinguishes it from adjacent getters like get_dns_settings or get_system_time. It stops short of explicitly naming a sibling it replaces or is replaced by.

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 by the resource name: an agent infers it should be called when NTP configuration is needed. There is no statement of when to prefer it over related tools (get_system_time, get_system_global) and no prerequisites such as needing a device_id or vdom context resolved first.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Show' implies a read, but it never explicitly states read-only safety, required permissions, or how the query behaves across vdoms. For a definition with zero annotation coverage, this is thin.

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

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

One front-loaded sentence with zero waste; the returned fields are packed into a tight parenthetical. Nothing could be removed without losing information.

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

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

Because there is no output schema, enumerating router-id/areas/networks/interfaces is useful compensation. However, with no annotations, no usage routing to the on-premise alternatives, and silent vdom semantics, the definition is only barely sufficient to call it correctly.

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

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

Schema coverage is 100%, so both device_id and vdom are already documented in the schema. The description adds no parameter-level meaning beyond that, which matches the baseline 3 when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Show the OSPF configuration') and enumerates the returned fields, so the agent knows exactly what it retrieves. It doesn't distinguish itself from closely related siblings like get_bgp_config or get_sdwan_config, but the resource is unambiguous.

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

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

There is no guidance on when to use this versus alternatives (e.g., get_routing_table or get_bgp_config), no prerequisites, and no noted exclusions. The agent must infer usage purely from the name.

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

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

No annotations are provided, so the description carries the full burden. 'Show' strongly implies a read-only operation and the listed counters describe the data returned, but it does not explicitly state read-only behavior, permissions required, or any rate/scope constraints.

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

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

The description is a single front-loaded sentence with little waste. The parenthetical API path is slightly redundant but still useful context and does not obscure the main purpose.

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

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

For a simple read tool with complete schema coverage, the description is adequate to select and invoke it. However, with no annotations or output schema, it could say more about read-only behavior, vdom scoping, and whether counters are live or historical.

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

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

Schema description coverage is 100%, so device_id and vdom are already documented by the schema. The description adds no parameter-specific meaning or format details beyond the schema baseline.

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

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

The description uses a specific verb ('Show') and names the resource clearly ('CPU/memory/session/uptime performance counters'). It is understandable without opening the schema, though it does not explicitly distinguish this from related siblings like get_system_resources or get_device_status.

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 only states what the tool does, with no guidance on when to use it versus alternatives. It does not mention conditions, exclusions, or sibling tools such as get_system_resources, get_device_status, or monitor_get.

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 does carry the burden, and it does disclose that the result is the active table (not the config) and enumerates the returned fields. It says nothing about permissions, VDOM scoping pitfalls, read-only nature, or table size/performance on large routing tables.

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 one-line purpose, then Parameters and Returns sections. The Returns block earns its place because there is no output schema; the Parameters block mildly repeats the schema but stays brief.

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

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

For a two-parameter read tool with no annotations and no output schema, the description covers purpose, parameter meaning, and the shape of the return values. Only sibling routing and operational caveats (size, VDOM requirement) are missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds the meaningful detail that vdom is optional and falls back to the device default, which the schema only conveys via default=null. That is a small but genuine addition beyond the schema.

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

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

States a specific verb and resource ("Get the current routing table") and scopes it to the active table including static, dynamic and connected routes, which implicitly separates it from config-oriented siblings like list_static_routes or get_bgp_config. It never names a sibling explicitly, so an agent must infer the boundary.

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

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

Usage is only implied: the word "current" and "installed" suggests live operational state rather than configuration, which helps against list_static_routes, but there is no explicit when-to-use/when-not guidance and no mention of lookup_route as the per-destination alternative.

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

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

No annotations are provided, so the description carries the full burden. 'Show' implies a read, but it never states that explicitly, nor does it mention required device access/permissions, whether the vdom scoping changes results, or how the configuration is returned. For a tool with zero structured safety metadata this is thin.

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

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

A single front-loaded sentence with no filler; the parenthetical contents list is efficient. It is arguably too terse rather than too long, so the only deduction is for missing rather than 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 description sketches the returned sections, which helps given there is no output schema, but omits vdom scoping semantics and the relationship to the overlapping sibling tools. Adequate but with clear gaps for an unannotated tool.

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

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

Schema description coverage is 100%, so both device_id and vdom are already documented in the schema. The description adds nothing about parameter behavior, such as what happens when vdom is null (the default) — baseline 3 applies.

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

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

States a specific verb ('Show') and resource ('SD-WAN configuration') and enumerates the sub-sections returned (zones, members, health checks, rules). This separates it from granular siblings like list_sdwan_members and list_sdwan_health_checks, though it doesn't explicitly acknowledge that relationship.

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 aggregate view versus the dedicated list_sdwan_members and list_sdwan_health_checks tools, which overlap directly with the returned content. The agent is left to infer that this is the bundled option.

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

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

With no annotations, the description carries the behavioral burden and does disclose meaningful details: application-control entries are in evaluation order with actions/categories/signatures, and web-filter categories are grouped by action. 'Show' implies a read operation, though permission and error behavior are not addressed.

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 main purpose and is structured into behavior, parameters, and returns. The parameter list largely duplicates the schema, but the overall text remains compact and readable.

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

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

For a detail tool with no output schema and no annotations, the return description is minimal: 'Profile settings and entries.' It explains special output formatting only for application and web filter profiles, leaving return behavior for antivirus, ips, dnsfilter, and ssl-ssh profiles poorly specified.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description repeats the parameter list and enum options but adds little semantic meaning beyond what the schema provides, making the baseline 3 appropriate.

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

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

The description states a specific verb and resource: show one security profile in depth. The phrase 'one ... in depth' implicitly distinguishes it from the sibling list_security_profiles, though it does not name that alternative explicitly.

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

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

There is no explicit guidance on when to use this tool versus list_security_profiles or other profile-related tools. It also does not state prerequisites such as obtaining a profile name first, so the agent must infer usage from the tool name.

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

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

No annotations are provided, so the description carries the full burden: it implies a read via 'Show' but never states that explicitly, and says nothing about permissions, rate limits, scope (single device vs. fabric-wide), or what the summary contains. For an unannotated tool this is a substantial gap.

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

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

A single front-loaded sentence with no filler; the parenthetical API path is compact and mildly useful for orientation. Nothing is wasted, though there is little content to be concise about.

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 two-parameter read tool with a fully documented schema needs only modest description, but with no annotations and no output schema the description should say more about the rating payload (score, categories) and that this is a non-mutating read.

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

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

Schema description coverage is 100% and both parameters (device_id, vdom) are documented in the schema, so the baseline of 3 applies. The description adds no parameter hints such as whether vdom is required for fabric-level results.

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 ('Show') and resource ('Security Fabric security rating summary'), plus the underlying API path, so the agent knows exactly what data comes back. It does not, however, distinguish itself from generic read siblings such as monitor_get or get_device_status, leaving that to inference.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives like monitor_get for other monitor endpoints. The agent must infer from the name alone that this is the tool for security rating data.

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 the categories of returned information, which is useful, but does not explicitly confirm read-only behavior, side effects, authentication requirements, or rate limits.

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

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

The description is front-loaded and structured with a clear Returns list, but the second sentence largely repeats the first, and the Returns list is somewhat generic. It is adequate but contains some redundant framing.

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

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

For a zero-parameter server-info tool with no output schema, the description sufficiently defines scope and enumerates the kinds of information returned. It does not need to explain parameters, and the return-value categories give the agent enough context to call it correctly.

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

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

The tool has zero parameters, so parameter semantics are not a concern. The description does not need to explain inputs, and the baseline for a zero-param tool is appropriate.

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

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

The description uses a specific verb and resource: 'Get detailed information about the FortiGate MCP server.' It clearly distinguishes a meta/server-information tool from device-configuration siblings, though it does not explicitly contrast itself with tools like health_check or get_system_resources.

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

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

It states what information is available but gives no when-to-use guidance, no conditions or exclusions, and no alternatives. An agent must infer that this is for inspecting the MCP server rather than a FortiGate device.

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, yet it discloses nothing beyond the field list: no note on required permissions, device reachability/timeout behavior, whether vdom scoping changes results, or error conditions when SNMP is disabled. For a monitoring call against a physical device this is a meaningful gap.

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

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

A single front-loaded sentence with zero filler. It is perhaps too terse given the missing context, but nothing in it is wasted.

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

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

For a simple two-parameter read with no output schema, the description does enumerate the returned fields, which is the minimum an agent needs. However, with no annotations and no output schema, it should say more about what 'status' contains and how failures surface when SNMP is not enabled on the device.

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

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

Schema description coverage is 100%, so device_id ('FortiGate device identifier') and vdom ('Virtual Domain') are already documented, warranting the baseline of 3. The description adds no semantics for either parameter, and its list of fields could be mistaken for inputs rather than outputs.

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 concrete verb ('Show') and a specific resource (SNMP agent status, contact, location, description), so an agent knows exactly what data comes back. It does not explicitly contrast with the nearby list_snmp_communities, but the distinction (agent sysinfo vs. community strings) is reasonably inferable from the wording.

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

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

The description gives no when-to-use guidance, no prerequisites (e.g. that device_id must be a reachable FortiGate), and no exclusions or alternatives. The agent must infer that this is a read-only diagnostic call from the verb 'Show' alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Show' signals a read-only retrieval and the parenthetical enumerates what comes back, but nothing is said about permission requirements, whether the vdom parameter scopes results, or error behavior for an unknown device_id.

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

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

A single front-loaded sentence with the returned-field list in parentheses; nothing redundant and no filler. The most useful information (what is retrieved) comes first.

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

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

For a simple two-parameter read with no output schema, the parenthetical field list effectively stands in for return-value documentation, which makes it callable without follow-up questions. The remaining gap is vdom scoping semantics, which matters on FortiGate but is unaddressed.

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

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

Schema coverage is 100% with only two parameters, both documented in the schema ('FortiGate device identifier', 'Virtual Domain'), so baseline 3 applies. The description adds no meaning about how vdom affects the returned settings or that device_id is mandatory.

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 ('Show') and a concrete resource ('SSL-VPN settings'), then enumerates the returned fields (status, port, source interfaces, portal mapping, tunnel IP pools). This distinguishes it reasonably from list_ssl_vpn_portals and list_ssl_vpn_sessions, though it does not name those siblings explicitly, so the boundary is inferred 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 implied: an agent can infer this is the read path for global SSL-VPN configuration on a device. There is no explicit when-to-use, when-not, or pointer to list_ssl_vpn_portals/list_ssl_vpn_sessions for portal or session data, leaving the choice to inference.

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

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

With no annotations, the description carries the burden; 'retrieves' signals a read-only operation, which is the main behavioral fact. It does not mention failure modes (unknown route_id, invalid vdom) or any permission/connection requirements, and the Returns list is generic rather than concrete field names.

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 purpose sentence is good, but the following sentence repeats it, and the Parameters block duplicates schema text almost verbatim. The Returns block earns its place because no 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 simple three-parameter read tool with no annotations and no output schema, the description covers the essentials and substitutes a coarse return summary. However, the return summary ('Complete route configuration', 'Status information') is too generic to tell an agent what fields to expect, leaving a gap for a 'detail' tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description largely restates schema text ('Identifier of the FortiGate device', 'ID of the route to query') but does add one genuine clarification: vdom is optional and falls back to the device default, which the schema's 'Virtual Domain' description omits.

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 ('Get detailed information for a specific static route') and contrasts implicitly with list_static_routes by emphasizing a single route. It never names the sibling tools (list_static_routes, get_routing_table, lookup_route) that could be confused with it, so 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?

The word 'specific' implies you must already know the route_id rather than searching, which is weak implicit guidance. There is no explicit statement of when to use this versus list_static_routes or lookup_route, and no prerequisites (e.g. device must be registered) are given.

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

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

No annotations are provided, so the description carries the behavioral burden. It communicates a safe read-only operation and lists the fields returned, but does not mention permissions, VDOM scoping behavior, or any limitations of the global view.

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

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

One front-loaded sentence with a colon-delimited list of covered settings. Every element earns its place and there is no filler or redundancy.

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

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

For a simple two-parameter read-only getter with full schema coverage, the description is largely complete: it states scope and enumerates the returned settings. It could be improved by clarifying VDOM behavior and differentiating from adjacent system getters, but no critical information is missing.

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

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

Schema description coverage is 100%, with device_id and vdom documented directly in the schema. The description adds no parameter-level meaning beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description uses a specific verb ("Show") and resource ("global system settings") and enumerates the main fields covered (hostname, admin ports/timeouts, timezone, management features). It is clear enough to distinguish from unrelated siblings, though it does not explicitly name nearby alternatives like get_ntp_settings or get_system_time.

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 "Show global system settings": it is clearly read-only inspection. However, there is no explicit guidance on when to use this versus other system-level tools such as get_system_time, get_ntp_settings, or get_dns_settings, which are close siblings.

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

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

With no annotations, the description carries the full behavioral burden. The verb 'Show' implies a read-only operation and the Returns section lists the monitored metrics, but it does not disclose permission requirements, whether vdom scope changes the result, or how current values are sampled.

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

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

The definition is short and front-loads its purpose in the first sentence. The Parameters section largely duplicates schema fields, but the overall structure remains efficient and easy to scan.

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

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

The description lists inputs and return categories, which is useful because there is no output schema. Still, with no annotations it leaves gaps around safe operation, prerequisites, and differentiation from other monitoring tools.

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

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

Schema description coverage is 100%, so both parameters are already documented. The description repeats that device_id identifies the device and vdom is optional, but adds no extra meaning such as expected identifier format or the effect of omitting vdom.

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: showing current CPU, memory, disk, and session usage for a FortiGate device. It is clear what the tool does, but it does not distinguish itself from nearby monitoring siblings such as get_performance_status or get_device_status.

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 phrase 'Show current... usage,' suggesting on-demand resource monitoring. However, there is no explicit guidance on when to choose this tool over get_performance_status, get_device_status, or other status-related siblings.

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

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

No annotations exist, so the description carries the full behavioral burden. 'Show' signals a read-only, non-mutating operation and the endpoint path hints the data comes from the live monitor subsystem rather than stored config, but permission requirements, whether the device is queried in real time, and failure behavior are unstated.

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

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

A single tight sentence with the resource front-loaded and the API path appended as supporting detail. Nothing is wasted, though the parenthetical path is of marginal value to an agent that cannot call the API directly.

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

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

For a simple two-parameter read tool with full schema coverage, the definition is nearly sufficient. Minor gap: with no output schema, the description could hint at what the response contains (current time, timezone, DST state), but for this level of complexity the omission is small.

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

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

Schema description coverage is 100%, with device_id ('FortiGate device identifier') and vdom ('Virtual Domain') already documented. The description adds no semantics beyond the schema, so the baseline 3 applies.

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

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

Specific verb ('Show') plus concrete resource ('device clock and timezone'), with the underlying API path (monitor/system/time) as corroboration. It is clearly distinct from siblings like get_ntp_settings or get_system_global, though it never names those alternatives to sharpen the boundary.

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

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

Usage is only implied: an agent can infer this is the tool for reading local time/timezone. There is no explicit guidance on when to prefer it over get_ntp_settings (the NTP configuration tool) or get_system_global, both of which are plausible confusion points in a large sibling set.

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 burden. It does disclose the return payload (complete config, port forwarding, interface assignments, status) and 'Get/retrieves' implies a read-only operation, but it says nothing about permission requirements, behavior with a wrong vdom or missing object, or whether device default fallback can mask errors.

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 the first sentence, followed by clearly separated Parameters and Returns sections. The line-wrapped prose is slightly padded ('comprehensive configuration details ... including all settings and mappings'), but nothing is wasted.

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

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

For a 3-parameter, non-destructive read with no output schema, the description supplies an adequate return-field summary and full parameter coverage. The only real gap is the absence of any behavioral or safety statement, which matters more here because no annotations back it up.

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

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

Schema description coverage is 100%, so all three parameters are already documented, and the description only restates them. It adds minor value by clarifying that vdom is optional and falls back to the device default, but not enough to exceed the baseline.

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

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

States a specific verb and resource: retrieve detailed configuration for one Virtual IP, which is implicitly the singular counterpart to list_virtual_ips. It does not name that sibling explicitly, but 'a specific Virtual IP' is enough for an agent to tell single-object read apart from listing.

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

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

Usage is only implied: an agent can infer this is the drill-down after list_virtual_ips, since it requires a device_id and a Virtual IP name. There is no explicit when-to-use/when-not, no mention of what to do if the name is unknown, and no stated prerequisites beyond the parameters.

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

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

With no annotations provided, the description carries the full behavioral burden, yet "Show" is the only signal that this is a read-only operation. Nothing is said about required device permissions, whether the vdom argument defaults to the management VDOM, or what happens if the device lacks a wireless controller.

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

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

A single well-formed sentence with the resource and the returned settings front-loaded; no filler, no hedging, nothing wasted. It is short precisely because it says little, but nothing in it is redundant.

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

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

A two-parameter, low-complexity read, but with no annotations and no output schema the description must disclose that this is a non-mutating read and roughly what a result looks like. It omits both, and says nothing about the vdom scoping parameter that affects which settings are returned.

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

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

Schema description coverage is 100% (device_id and vdom are both documented in the schema), so baseline 3 applies. The description adds no meaning beyond the schema for either parameter — it does not explain the vdom default of null or how device_id is resolved.

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