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

Description opens with [READ-ONLY] and lists the actual work performed: user-ID mapping and groups, security-policy-match with the user, application rule lookup, and explained traffic logs. This adds real behavioral context beyond the annotations, including that it internally tests policy matching and searches logs.

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?

Roughly 50 words pack read-only status, what the tool analyzes, and when to use it, with no filler. The [READ-ONLY] tag and action verb are front-loaded, and the 'Use for' tail is appropriately placed.

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

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

Given 10 parameters and no output schema, the description communicates the tool's scope and outputs conceptually. It doesn't specify how to choose between user and src_ip as the source or describe the result format, but the high schema coverage mitigates most of that 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 90%, so the schema already documents the parameters. The prose adds light semantic glue, e.g. 'source -> destination:port', 'requested application', and 'App-ID', but does not meaningfully extend the parameter descriptions.

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

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

States 'Analyzes a flow (source -> destination:port) on a firewall' with a specific verb and resource, then enumerates four concrete analysis outputs. This clearly differentiates it from sibling diagnostic tools like diagnose_user_blocks or diagnose_threat_block, which target different questions.

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 explicit use cases: 'no rule allows X', upload app functions, App-ID or network issues. This is clear when-to-use guidance, though it does not mention exclusions or name alternative diagnostic tools, so it stops short of full routing.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description reinforces this with the '[READ-ONLY]' prefix and adds behavioral detail about what is analyzed (applied profile, exception existence, verdict), which goes beyond the annotations. No contradictions are present.

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, information-dense sentence that front-loads the read-only nature and the primary purpose, then lists the discrete outputs. While it is long, every element contributes to understanding what the tool does, and it is appropriately structured for a diagnostic tool.

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

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

Given the tool's complexity (8 parameters, no output schema), the description clearly states what findings it returns (log, rule, profile, exception, verdict), which is essential for an agent to interpret the result. It does not describe the exact response format or edge cases, but the enumerated outputs provide sufficient context for a diagnostic 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 all eight parameters are already documented with types, patterns, and examples. The description does not add parameter-specific semantics but does provide high-level context about how the tool uses them (e.g., resolving the applied profile). This meets the baseline for high coverage.

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

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

The description opens with a clear verb ('Analyzes') and names the resource ('threat/file block') plus the specific categories (antivirus, WildFire, etc.). It then enumerates exactly what the tool finds (log, rule, profile, exception status, file-blocking rule, WildFire verdict), which unambiguously distinguishes it from sibling log-fetching tools like get_threat_logs.

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 a diagnostic use case for investigating why a block occurred, and its read-only nature aligns with a troubleshooting role. However, it does not explicitly state when to prefer this tool over alternatives such as get_threat_logs or diagnose_flow, nor does it provide conditions or exclusions. The purpose is clear enough that an agent would infer the correct context.

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

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

Annotations already declare readOnlyHint and non-destructive behavior, and the description reinforces that with a leading '[READ-ONLY]' label. It goes beyond annotations by disclosing what analysis components will be included and that the tool explicitly avoids recommending already-existing categories, which is useful behavioral context.

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

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

The description is a single dense sentence that front-loads the read-only nature and core purpose, followed by a structured list of investigation areas. It earns its length by conveying the full diagnostic scope and the unique 'prevent duplicate category' outcome, with only minor redundancy from repeating the read-only annotation.

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 complex diagnostic tool with seven optional parameters and no output schema, the description covers the essential expected results: categories, PAN-DB classification, relevant rules/profiles, logs, and conclusions. It does not detail output formatting or the effect of each optional parameter, but those are largely covered by the schema, and the description conveys enough context for successful use.

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

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

The input schema has 100% description coverage for all 7 parameters, including defaults and examples, so the description does not need to explain parameters. The description only hints at the 'user' parameter through 'recent URL logs for the user' and adds no parameter syntax or format details beyond the schema.

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

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

The description states a clear verb and resource: 'Full analysis of why a URL is blocked/allowed.' It further specifies the investigation scope (custom categories, PAN-DB category, rules/profiles, logs, conclusions) and the unique goal of preventing proposals for categories that already exist, which distinguishes it from sibling diagnostic 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 makes the intended use case clear: when a URL is blocked/allowed and the user needs to understand why, especially before proposing a new custom category. It does not explicitly name alternative tools or exclusions, so the guidance is good but not exhaustive.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond the annotations: it aggregates across seven log types, groups and explains blocks (which layer blocked, why, what to check next), and with reported_url expands scope to related domains. It also implies a timeline construction. This is useful behavioral disclosure that goes beyond the structured fields.

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

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

Two sentences, front-loaded with the most important usage signal ('START HERE'), and every clause earns its place. The first sentence covers scope, behavior, and output; the second covers the conditional expansion with reported_url. No filler or repetition of schema details.

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

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

For a complex diagnostic tool with 7 optional parameters and no output schema, the description gives a strong high-level picture: what logs are searched, what the output looks like (timeline, grouped/explained), and when to use reported_url. It doesn't detail the output format or edge cases (e.g., what happens with no results), but the description is sufficient for an agent to select and invoke the tool correctly, especially given the 100% schema coverage.

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 7 parameters. The description adds value by explaining the role of reported_url (flags blocks on OTHER domains) and implicitly the user/src_ip focus, but it doesn't add detail on period vs incident_time tradeoffs or max_groups semantics beyond what the schema provides. Baseline 3 is appropriate when the schema carries the parameter documentation burden.

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

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

The description opens with a clear directive ('START HERE for a ticket') and a specific verb ('Builds a timeline') tied to a concrete resource (everything that blocked a user or source IP across multiple log types). It explicitly names the log categories and the grouping/explanation behavior, and it distinguishes itself from sibling diagnostic tools by being the entry point for ticket diagnosis. This is a specific, non-tautological statement that an agent can act on.

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

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

The description explicitly says 'START HERE for a ticket', which is a strong when-to-use signal. It also names the alternative behavior with reported_url (flags blocks on OTHER domains at the same time), which tells the agent when to include that parameter. While it doesn't name a specific sibling to avoid, the 'START HERE' framing and the cross-log scope make the usage context clear and distinct from the many get_* and diagnose_* siblings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, making the '[READ-ONLY]' prefix redundant. However, the description adds genuine value beyond the annotations by disclosing the dual data sources (Panorama config plus live firewall content) and by noting that EDL exception lists are included in the lookup — behavioral details an agent would not infer from the annotations alone.

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 dense sentence front-loads the read-only nature and packs in purpose, scope, and exception-list coverage without wasted words. The '[READ-ONLY]' prefix slightly duplicates the readOnlyHint annotation, but overall the length is appropriate and every clause earns its place.

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

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

For a read-only membership-check tool with 100% schema coverage, safety annotations, and no output schema, the description adequately covers the query value, data sources, and exception behavior. The only gap is the lack of a stated return format (e.g., which EDL matched vs. a simple boolean), but the tool's behavior is simple enough that an agent can reasonably infer the result.

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

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

Schema description coverage is 100% with meaningful per-parameter descriptions, so the baseline of 3 applies. The main description restates the value domain ('IP, domain or URL') that the schema already documents and contributes little parameter-level semantics beyond what the structured schema provides.

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

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

The description uses a specific verb and resource — 'Checks whether an IP, domain or URL is present in the External Dynamic Lists applying to a firewall' — and adds distinguishing scope: config from Panorama, current firewall content, and EDL exception lists. This clearly differentiates it from siblings like userid_lookup, test_security_policy_match, and test_url_category, all of which serve different purposes.

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 its use case (verifying EDL membership) through purpose clarity, but it never explicitly names alternatives or states when-not-to-use conditions, such as 'for user mapping use userid_lookup.' Some guidance exists at the parameter level — 'Usually omit it: the firewall is chosen from device_group, or from the user's/IP's recent traffic' — but no comparative routing is present in the main text.

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

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

Beyond the readOnlyHint annotation, the description explains matching behavior across many rule attributes, inheritance semantics in evaluation order, and the log-forwarding flag on output. This is substantial behavioral disclosure with no contradiction to the annotations.

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

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

Four concise sentences front-load the core operation and then add targeted detail on matching and scoping. Every sentence contributes distinct information without redundancy.

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

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

The description plus schema cover the essential invocation details for a 7-parameter, read-only search tool. It does not describe the full return shape or what happens when both device_group and device are provided, but these are minor gaps for invocation.

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

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

With high schema coverage, the baseline is 3, but the description enriches the device_group and device parameters by explaining inherited rules and evaluation order, and clarifies the contains matching scope. This adds meaning beyond the schema's simple descriptions.

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

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

The description clearly specifies a search operation over security or decryption rules in Panorama's running configaine and lists the fields matched. It does not explicitly name sibling tools like get_security_rules or panorama_get_pre_rules, but the search vs. get distinction is functionally 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 gives useful scoping context for device_group vs. device and notes that output flags rules without log forwarding. However, it does not explicitly state when to use this search tool over sibling get tools, nor provide exclusion criteria, so guidance remains implicit rather than direct.

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

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

Annotations already declare readOnlyHint=true and destructive=false, but the description adds value by naming the exact actual operation ('Exeecutes: show session info'), which lets an agent predict the firewall command and behavior. It also clarifies that the result is a count and summary rather than raw session listings. No contradictions with annotations.

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

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

The description is a single efficient sentence with the read-only marker front-loaded, followed by the precise function and underlying command. Every word carries meaning and there is no repetition or filler.

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

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

For a simple, read-only, one-optional-parameter tool, the description is complete: it states what is retrieved, names the underlying command, and the schema already covers the firewall parameter. No output schema exists, but the description adequately indicates the result ('count and summary'), so 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%: the lone 'firewall' parameter is already documented with when it is required/optional. The tool description adds no additional parameter meaning, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Retrieves') and resource ('ctive session count and summary from the firewall'), and the stated CLI command 'show session info' makes the tool's function unmistakable. It is clearly distingushed from sibling get_* diagnostic tools by focusing on session info.

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

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

The description gives no explicit when-to-use guidance, comparison with alternatives, or exclusions. While it is obviously intended for checking active session information, it does not state conditions or direct agents toward or away from any sibling tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the config path and a potential filtering qualifier, which is useful context beyond the annotation. However, it does not clarify the return shape, whether the 'contain multiple address objects' phrase is a filter, or any edge-case behavior.

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

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

The description is only two short sentences with no filler. The read-only marker and primary action are front-loaded, and the config path is a useful, compact addition.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description gives enough information to invoke it: what it retrieves and where it reads from. The ambiguous wording about 'multiple address objects' and the lack of return-format detail are minor gaps.

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

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

The single firewall parameter is fully described in the schema with 100% coverage, so the description does not need to add parameter details. The description also adds no extra semantics about the parameter or how it affects the result, so the baseline of 3 applies.

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

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

The description states a specific action ('Retrieves') and resource ('address groups'), and further identifies the config path. It is clearly distinct from sibling tools like get_address_objects and get_service_groups. The qualifier 'that contain multiple address objects' is slightly ambiguous, but it does not obscure the core purpose.

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

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

No guidance is given about when to use this tool versus siblings such as get_address_objects, get_service_groups, or add/delete_address_group. The read-only marker implies safe querying, but there are no explicit exclusions, prerequisites, or alternative conditions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context by naming the config path it reads from and specifying the object types returned, but it does not disclose behavior such as pagination, response size, or handling when no address objects exist. This is adequate but not rich.

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

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

The description is one compact, informative sentence plus a useful config path reference. It front-loads the core behavior and avoids unnecessary filler. The redundant '[READ-ONLY]' marker is minor and does not hurt clarity.

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

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

For a low-complexity, single-optional-parameter read-only tool with annotations covering safety and schema covering params, the description is largely complete. It explains what is retrieved and where the data comes from. Since there is no output schema, slightly more detail about the return format would be ideal, but the core context is sufficient for an agent to call it safely.

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

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

Schema description coverage is 100%, and the only parameter, firewall, is documented in the schema with guidance about when it is required. The description adds no additional parameter semantics beyond that, which is acceptable because the schema already carries the meaning.

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

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

The description clearly states the action ('Retrieves all address objects') and the resource ('defined on the firewall'), and clarifies that address objects include IP addresses, ranges, and FQDNs. This distinguishes it from siblings like get_address_groups or add/delete address-object operations.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it, nor does it compare against related siblings such as get_address_groups or get_config. The read-only label implies a safe listing operation, but no concrete selection criteria are provided.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description matches with '[READ-ONLY]' and 'Retrieves'. It adds the config path, which provides extra context about where data is read from, enhancing transparency beyond annotations.

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

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

The description is a single, efficient sentence plus a path reference. It is front-loaded with the READ-ONLY tag and the core purpose, with no wasted words.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description is nearly complete. It explains what is retrieved and the source. A minor gap is that it does not describe the return format (e.g., list vs. single object), but this is not critical 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% — the single parameter 'firewall' has a clear description. The tool description adds no additional parameter information, so it meets the baseline of 3 for full schema coverage.

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

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

The description states a specific verb ('Retrieves'), a specific resource ('administrator role definitions and their permissions'), and the config path. It clearly distinguishes from siblings like get_admins (which deals with users) by focusing on roles.

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

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

The description does not explicitly say when to use this tool versus alternatives. It implies usage for reading admin roles, but provides no exclusions or comparisons to other read-only tools in the sibling list.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a concrete config source path (/config/mgt-config/users) and a [READ-ONLY] marker, but it does not disclose return format or auth prerequisites, which would add richer 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?

Two short sentences with zero fluff. The verb and resource are front-loaded, and the config path is a compact, useful addition. Every word earns its place.

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

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

For a simple read-only query tool with one optional, fully documented parameter and annotations covering safety, this description is complete. It states what is retrieved and where from; nothing an agent needs to call it correctly 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% — the single 'firewall' parameter is fully documented in the schema, including when it is required. The tool description adds no additional parameter detail, so the baseline score of 3 applies.

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

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

Description uses a specific verb ('Retrieves') plus a precise resource ('all administrator accounts configured on the firewall'), leaving no ambiguity about the tool's function. It distinguishes itself from sibling tools like get_admin_roles (accounts vs. roles) even without naming them.

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

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

No explicit when-to-use guidance or named alternatives, but the purpose statement clearly implies the use case: fetch all admin accounts. The large sibling list includes similar get_* tools, so explicit routing would help, but the usage is reasonably self-evident.

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

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

Annotations already declare the tool as read-only and non-destructive, so the safety profile is covered. The description adds value by revealing that it executes a `show system info` command and extracts signature fields, giving the agent insight into the underlying behavior and scope. This is genuine added context beyond the annotations, though it stops short of describing authentication or rate-limit requirements.

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

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

The description is compact and front-loaded: it presents the primary result in the first sentence and the execution method in the second. The only minor waste is the redundant `[READ-ONLY]` prefix, which duplicates the annotation and adds no new information. It is otherwise tight and efficient, warranting a 4 rather than 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 tool with a single optional parameter, no output schema, and no nested objects, the description gives a reasonable summary of what data is returned (versions and release dates). However, because there is no output schema, it would be helpful to state the return structure or at least clarify how the results are presented. It also leaves the relationship to siblings like `get_wildfire_status` unaddressed, which keeps it at an acceptable but not complete level.

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

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

The input schema has one optional parameter (`firewall`) with a complete description (100% coverage), so the schema alone adequately documents the parameter. The tool description does not add any additional meaning or constraint about the parameter, which is acceptable given the baseline of 3 for high schema coverage. No compensation is needed.

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

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

The description clearly states the tool retrieves current antivirus, threat, and WildFire signature versions and release dates, naming the resource and data extracted. It also cites the underlying command (`show system info`) which reinforces the purpose. However, it does not explicitly distinguish itself from siblings like `get_wildfire_status` or `get_content_versions`, so it gets a 4 rather than 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 explicit 'use when' or 'use instead' guidance, and no mention of alternatives. The implied usage is clear from the description—an agent would know to call this when it needs antivirus/threat/WildFire signature versions—but no exclusions or comparisons are provided. This meets the 'implied usage' level, not the clearer guidance of higher scores.

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

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

Annotations already establish read-only and non-destructive behavior, so the bar is lower. The description adds useful behavioral context beyond annotations by stating that the tool reads a specific config path: /config/.../vsys/entry/application-filter. This helps the agent understand the data source and hierarchical scope.

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

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

The description is compact and front-loaded: read-only marker, exact tool purpose, and config path in one efficient sentence. There is no filler or repetition of structured data.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description provides enough context: what it retrieves, why it is used, and where the data lives. It does not describe the return shape in detail, but that is a minor gap for such a focused getter.

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 single optional 'firewall' parameter is fully documented in the schema. The description itself does not repeat or expand on parameter semantics, but it does not need to because the schema already explains when the parameter is required.

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

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

States a specific verb and resource: 'Retrieves application filters used for application-based policy rules.' This clearly distinguishes it from sibling getters like get_routing_table or get_zones. The read-only prefix and config path add further precision.

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

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

The description gives clear context for when the tool is relevant: when working with application-based policy rules and needing application filters. It does not explicitly name alternatives or exclusions, but the purpose statement is sufficient for tool selection among the many sibling getters.

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

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

The description adds the exact command executed ('show arp entry all') beyond the annotations, giving the agent concrete insight into the underlying operation. The [READ-ONLY] prefix reinforces the annotation, and there is no contradiction or hidden side effect disclosed or omitted.

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, efficient sentences with no redundant filler. The read-only indicator and purpose are front-loaded, and the exact command is provided in the second sentence.

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

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

For a simple read-only tool with one optional parameter, no output schema, and safety annotations already present, the description is sufficiently complete. It could mention the returned fields or format, but that is not critical given the straightforward nature of the operation.

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

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

Schema description coverage is 100%, so the single 'firewall' parameter is already fully documented in the schema. The description adds no additional parameter-specific meaning, which is acceptable given the baseline for full schema coverage.

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

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

States a specific verb and resource: 'Retrieves ARP table entries from the firewall.' It clearly identifies the data being fetched and is distinct from all sibling tools, none of which target ARP tables.

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

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

The description makes it clear this tool is for reading ARP table entries from a firewall. It does not explicitly name alternatives or exclusions, but the purpose is specific enough that an agent can select it appropriately among the get_* 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?

The readOnlyHint and destructiveHint annotations already declare the safety profile, so the description does not need to re-establish that. It adds useful operational detail: the exact config path and the profile types included, which provides context beyond the annotations.

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

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

Two sentences with no filler: the operation, protocol coverage, and config source are all stated efficiently. The read-only marker is front-loaded, and every sentence contributes useful 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 simple one-parameter, read-only getter with full schema coverage and safety annotations, the description is largely complete. The listing of included protocols partially conveys return content, though a bit more detail about the response structure 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?

The single parameter is fully documented in the input schema, including when it is required versus optional. The description adds no additional parameter-specific semantics, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Retrieves') with a clear resource ('authentication profiles') and names the contained protocols (RADIUS, LDAP, TACACS+). This distinguishes it from the many other get_* sibling tools without ambiguity.

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

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

No guidance is given on when to use this tool versus alternatives, nor are there exclusions or prerequisites. The config path gives context about where the data comes from, but not why an agent should select this tool over other getters.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the config source path, which is useful context, but it does not disclose other behavioral traits such as authentication requirements, output size limits, or response formatting.

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

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

The description is compact and front-loaded with the read-only indicator and core action. The '[READ-ONLY]' prefix is somewhat redundant with the annotation, but the overall two-sentence structure is efficient and each element earns its place.

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

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

For a simple read-only tool with a fully documented parameter and safety annotations, the description is nearly complete. It could be improved by indicating what the returned data contains (e.g., certificate details, validity dates), but this is not necessary for correct invocation.

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

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

Schema description coverage is 100%, with the 'firewall' parameter fully documented ('Target firewall name (from firewalls.json). Required when multiple firewalls are configured; optional otherwise.'). The description adds no parameter-level information, so the baseline of 3 applies.

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

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

The description states a specific verb and resource: 'Retrieves SSL/TLS certificates configured on the firewall.' This is clearly distinct from the many sibling get_* tools, and the added config path '/config/shared/certificate' further pins down exactly what is read.

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

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

There is no guidance on when to use this tool versus alternatives like get_config_xpath or run_show_command. The description merely states what it does, leaving the agent to infer usage from the tool name rather than from explicit when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's '[READ-ONLY]' prefix adds no new safety information. The description does add that it uses the PanOS log API with type=log and that results are 'recent,' which is modest behavioral context. No rate limits, pagination, or return format details are provided, but annotations cover the main safety profile.

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

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

The description is a single, front-loaded sentence that conveys purpose, API context, filtering, and result limiting without fluff. The '[READ-ONLY]' prefix is redundant with the annotations, which keeps it from being flawless, but the overall structure is compact and effective.

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 log retrieval tool with fully documented parameters and safety annotations, the description covers the essential purpose and capabilities. The main missing piece is return-format or time-window context, but no output schema exists and the description does not mislead. It is sufficient for an agent to select and invoke the tool correctly in most cases.

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

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

Schema description coverage is 100%, so the schema fully documents all three parameters: nlogs, query, and firewall. The description's mention of 'filtering by query and limiting result count' aligns with the query and nlogs parameters but does not add meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('Retrieves') and resource ('recent configuration change logs from the firewall') with an explicit API context ('PanOS log API type=log'). This clearly distinguishes it from sibling log tools like get_system_logs, get_traffic_logs, get_threat_logs, and get_url_filter_logs.

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

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

The description provides clear context: use this for configuration change logs from a firewall. It mentions filtering by query and limiting result count, which gives practical invocation guidance. It does not explicitly name alternatives or state when not to use it, but the resource type itself makes the intended use clear.

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

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

Annotations already mark the tool as read-only and non-destructive; the description adds [READ-ONLY] and clarifies that it targets the configuration tree. However, it does not disclose output format, error behavior, or any other behavioral nuances beyond what annotations already communicate.

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

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

Two sentences with no fluff. The read-only marker is front-loaded, and the second sentence earns its place by defining the tool's scope as the entire configuration tree.

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 complete schema documentation and safety annotations, the description is functionally complete. It could mention the return format or explicitly bound configuration-tree vs operational-state reads, but these are minor given the simple contract.

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%: both xpath and firewall have meaningful descriptions, including an example and the multi-firewall condition. The description itself adds no parameter-level detail, so the schema carries the full semantic burden.

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

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

The description uses a specific verb ('Retrieves') and resource ('configuration at a specific XPath location'), then clarifies it can query any part of the PanOS configuration tree. This clearly distinguishes it from the many specialized object-specific getter tools 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 description implies this is the general-purpose fallback for reading arbitrary configuration paths, but it never explicitly says when to prefer it over specialized getters or run_show_command. It provides context but no when-not-to-use guidance or named alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description reinforces read-only with '[READ-ONLY]' and adds the underlying operation 'Executes: request content upgrade info,' which provides additional behavioral context beyond the annotations. It doesn't add auth/rate limit details, but that is acceptable given annotations cover the safety profile.

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

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

Two concise sentences with no filler. The read-only marker is front-loaded, followed by purpose and execution detail. Every word earns its place and the structure is easy to scan.

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

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

For a simple read-only getter with one optional parameter, the description provides sufficient context. It names the resource, the categories, and the underlying command. It doesn't need to cover return details given no output schema and the informational nature of the tool, though it could have mentioned the output format.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific information; the optional 'firewall' parameter is fully documented in the schema already with details about when it is required.

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

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

The description states a specific action ('Retrieves') and a specific resource ('content update versions') with the categories (antivirus, applications, threats). This distinguishes it from siblings like get_antivirus_version, which is narrower in scope.

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

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

The description does not explicitly state when to use this tool versus alternatives. It implies broader coverage by listing three content categories but doesn't name sibling tools or exclusion criteria. An agent could infer from the category list, but there is no explicit when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with a READ-ONLY tag. It adds the config path '/config/.../profiles/decryption', which is useful context about the data source, but it does not describe return format, potential absence of profiles, or any other behavioral details.

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

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

The description is extremely concise: one sentence with the READ-ONLY hint front-loaded and the config path included. Every element earns its place with no redundant wording.

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

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

For a simple read-only tool with one optional parameter and clear annotations, the purpose and config source are adequately stated. However, there is no output schema and no description of what the returned decryption profiles contain or how to interpret the result, leaving some ambiguity for an agent.

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

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

Schema description coverage is 100%, so the single optional 'firewall' parameter is already fully documented in the schema. The description does not add any additional parameter semantics, so the baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Retrieves SSL decryption profiles.' It also adds a concrete config path, which makes the target resource unambiguous. The name and description together clearly distinguish this from sibling tools like get_decryption_rules and get_security_profiles.

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

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

There is no guidance about when to use this tool versus alternatives such as get_decryption_rules or get_security_profiles. The description only states what the tool does; it does not mention exclusions, prerequisites, or a decision context.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with '[READ-ONLY]'. The config path adds modest behavioral context about where the data is read from, but it does not disclose details like output shape, pagination, or firewall-specific behavior. Given the annotations cover the safety profile, a 3 is appropriate.

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

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

Two short sentences with no filler. The read-only nature is front-loaded, and the config path detail is useful without being verbose.

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

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

For a simple read-only getter with one fully documented optional parameter and safety annotations already present, the description is mostly complete. It could mention what the response contains or how rules are returned, but the low complexity and explicit path context make this a minor gap.

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

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

There is only one parameter and the schema already describes it fully, including the 'Required when multiple firewalls are configured' condition, so schema coverage is 100%. The description adds no further parameter-level meaning, 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 ('Retrieves') and a precise resource ('SSL decryption policy rules'), which distinguishes it from nearby siblings like get_decryption_profiles. The addition of the config path removes any ambiguity about which rulebase is being read.

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

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

No guidance is given about when to use this tool versus alternatives such as get_security_rules, get_decryption_profiles, or get_pbf_rules. The tool name implies the purpose, but the description does not state conditions, exclusions, or prerequisites beyond the optional firewall parameter.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only behavior is covered. The description adds the exact command executed, which is helpful context, but it does not disclose return format, whether output can be large, or any filtering/pagination behavior. That is acceptable for a simple read-only command, but no extra behavioral context beyond the annotation is added.

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

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

The description is compact and information-dense: one sentence states purpose, read-only nature, and the exact CLI command. It is front-loaded and avoids unnecessary detail, though it could have added a brief note about expected output.

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

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

For a one-parameter read-only tool, the definition is complete enough to invoke correctly, but there is no mention of possible response shape or how many leases might be returned. Since there is no output schema, a brief hint about the return data (e.g., lease list with IP/MAC) would improve completeness.

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

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

The schema has one optional parameter (firewall) with a clear description, and schema description coverage is 100%. The description does not need to add much; it correctly implies the firewall parameter is only required when multiple firewalls are configured, matching the schema's optional-required condition.

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

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

The description clearly identifies the tool as retrieving DHCP server lease information, specifies a read-only nature, and names the exact firewall command executed. It distinguishes itself from sibling tools like get_arp_table / get_routing_table in that it targets DHCP leases specifically.

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

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

The description implies usage for querying DHCP lease info and the schema clarifies when the firewall parameter is needed. However, it does not explicitly state when to choose this over alternatives, nor does it mention that no write/mutation is involved, though the READ-ONLY prefix partially covers that.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with '[READ-ONLY]' and the exact config path. It does not disclose error behavior, permissions, or output format, but for a simple read operation with these annotations, the description adds adequate context.

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

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

The description is two short, front-loaded sentences with no filler. It states the operation type, the resource, and the relevant config path without unnecessary detail.

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

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

For a read-only tool with one optional parameter and a fully documented schema, the description plus annotations are sufficient to invoke it correctly. The lack of an output schema and the broad term 'configuration' leave some ambiguity about the exact return fields, so it is not quite a perfect 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?

The input schema provides 100% coverage for the single optional parameter, including the conditional requirement when multiple firewalls exist. The tool description itself does not add parameter semantics beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Retrieves') and a specific resource ('DNS proxy configuration'), and it adds the config path. No sibling tool targets DNS proxy specifically, so it is clearly distinguishable.

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

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

The description gives no guidance on when to use this tool versus alternatives such as get_config. The only usage-related hint appears in the schema's parameter description about the firewall parameter, which addresses parameter requirements, not tool selection.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false; the description reinforces this with '[READ-ONLY]' and adds the concrete config path it reads. This provides useful behavioral context beyond the structured annotations, though it doesn't describe auth, rate limits, 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?

Two short sentences, front-loaded with the read-only marker and the core action. No filler or redundant content.

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

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

For a simple read-only tool with one optional parameter and full schema coverage, the description is mostly complete: it states the resource and config path, and annotations cover safety. It could optionally describe the shape or content of the returned profiles, but that is not essential for invoking the tool correctly.

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

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

The input schema has 100% coverage for the single optional firewall parameter, so the description need not add parameter details. The description adds no parameter semantics beyond the schema, matching 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?

The description uses a specific verb ('Retrieves') with a precise resource ('DoS protection profiles') and even names the config path. This clearly differentiates it from sibling profile tools like get_security_profiles and get_decryption_profiles.

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

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

The description implies the tool is for reading DoS protection profiles, but it does not explicitly state when to choose it over sibling profile tools or give any exclusion criteria. The config path adds context but no decision guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description reinforces this with the 'READ-ONLY' label and adds the exact command executed ('show system info'), which is useful context. It does not discuss auth or rate limits, but for a read-only informational command with no side effects, the disclosure is sufficient. No contradiction with the annotations.

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

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

The description is two tight sentences with no fluff. The read-only marker is front-loaded, the purpose is stated in the first sentence, and the underlying CLI command is provided in the second. Every word earns its place.

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

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

This is a simple one-parameter, read-only tool with no output schema. The description names the returned fields, the schema fully defines the optional target parameter, and the annotations cover the safety profile. Nothing essential for an agent to invoke this tool correctly 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%, so the parameter is fully explained in the input schema: 'Target firewall name (from firewalls.json). Required when multiple firewalls are configured; optional otherwise.' The tool description itself adds no additional parameter detail, which maps to the baseline 3 for high schema coverage.

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

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

The description states a specific verb and resource: 'Retrieves system information ... from the PanOS firewall' and enumerates the exact fields (hostname, model, serial, software version). This clearly distinguishes it from siblings like get_system_resources or get_config, and it adds the concrete command 'show system info' to remove any ambiguity.

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

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

It gives clear context: use this tool when you need identifying system information from a PanOS firewall. The schema further documents when the single parameter is required ('Required when multiple firewalls are configured'). However, it does not explicitly name alternatives or exclusion conditions compared with sibling read-only tools such as get_system_resources or list_firewalls, so it misses the fifth point.

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

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

Annotations already carry readOnlyHint=true and destructiveHint=false, and the description repeats this with '[READ-ONLY]'. It adds one useful behavioral detail—the exact config path—but does not disclose output shape, error cases, or effects of the optional firewall parameter.

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 read-only flag and action. Both sentences add value: one states the resource, the other the source path.

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

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

For a low-complexity, one-optional-parameter read-only getter, the description plus schema and annotations are nearly sufficient. The only minor gap is that no output schema exists and the description does not describe the return shape, but the resource name and path make the expected output clear enough.

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 single optional parameter is fully documented in the schema with its own description, so the tool description does not need to add much. It adds no parameter-level information, but schema coverage is 100%, matching 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 action ('Retrieves') and a specific resource ('GlobalProtect gateway and portal configuration'), and includes the config path. This is enough to distinguish it from sibling tools like get_globalprotect_users and gp_current_users.

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

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

The description implies usage: call it when you need GlobalProtect gateway/portal configuration. It does not explicitly name alternative tools or state when not to use it, leaving selection among the many get_* siblings to inference.

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

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

Annotations already declare the operation read-only and non-destructive, and the description reinforces this with a [READ-ONLY] prefix. It also adds value by disclosing the exact underlying command ('show global-protect-gateway current-user'), which gives the agent concrete knowledge of what will be executed.

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

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

The description is two compact sentences with no filler. The read-only marker and core purpose are front-loaded, and the underlying command is included as useful supporting detail.

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

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

For a simple read-only retrieval tool with one optional parameter, the description is nearly complete: it states what is retrieved, the command executed, and the schema documents the parameter. The lack of an output schema could have been compensated with return-format details, but this is a minor gap.

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

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

Schema description coverage is 100%, so the input schema fully explains the 'firewall' parameter. The description itself adds no additional parameter-level meaning beyond what the schema already provides, so the baseline score of 3 applies.

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

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

The description states a specific verb ('Retrieves') and resource ('currently connected GlobalProtect VPN users'), and it names the exact command executed. However, it does not explicitly differentiate itself from the sibling tool 'gp_current_users', which appears to serve a similar purpose.

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

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

There is no guidance on when to use this tool versus alternatives such as 'gp_current_users' or 'get_globalprotect_config'. The only usage hint is about the optional firewall parameter, which is handled by the schema and does not help with tool selection.

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

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

Annotations already disclose read-only and non-destructive behavior, and the description adds context beyond them by naming the exact underlying command ('show high-availability state') and the returned information (state and peer information). It does not detail output format, but the described behavior is clear and consistent with annotations.

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

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

Two compact sentences, with the read-only nature flagged first, then purpose, then the exact command. No filler or redundancy.

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

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

The simple one-parameter read-only tool is well described: purpose, target, exact command, and general return content. No output schema exists, but 'state and peer information' gives an agent enough expectation, and the optional firewall parameter is covered by the schema.

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

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

The schema fully covers the only parameter (firewall) with a clear description. The tool description adds no parameter-specific detail, but with 100% schema coverage the baseline 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 ('Retrieves'), the resource ('high-availability (HA) state and peer information'), and the target ('the firewall'). This differentiates it from nearby get_* and panorama_* siblings, and it names the exact command executed.

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

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

The description clearly establishes the intended use for reading HA state and peer information from a firewall, and the read-only flag sets expectations. It does not explicitly name alternatives or exclusions, but there is no obvious HA-status sibling and the firewall context is explicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with a [READ-ONLY] prefix. It adds meaningful behavioral context by exposing the exact executed command and the kind of data returned, which goes beyond the annotation defaults.

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

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

The description is compact and front-loaded: the read-only tag, the purpose, the returned data, and the underlying command all appear in two concise sentences. There is no filler or redundant restatement of the tool 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 tool with one optional parameter and no output schema, the description covers the returned fields (status, IP addresses, configuration) and the execution behavior. Nothing essential is missing for an agent to select and invoke this tool correctly.

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

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

Schema description coverage is 100%, and the firewall parameter is already documented in the input schema. The description does not add extra semantics about the parameter, but it also does not need to because the schema fully covers validation and purpose.

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: 'Retrieves all network interfaces with their status, IP addresses, and configuration.' This is immediately distinguishable from sibling tools like get_routing_table or get_vlans. Adding the exact underlying command 'show interface all' further reinforces what the tool does.

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

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

The description clearly conveys that this is the tool for retrieving interface-level information, which is enough context for an agent facing many get_* siblings. It does not explicitly mention alternatives or when-not-to-use cases, but no closer alternative exists in the sibling list.

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

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

The annotations already declare readOnlyHint and destructiveHint, so the description does not need to prove safety. It adds value by disclosing the underlying command ('show vpn ipsec-sa') and the returned data type (status and security associations), giving the agent a clearer expectation of 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?

Two sentences with no filler. The READ-ONLY marker is upfront, the core action is stated immediately, and the command detail adds practical specificity without 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 tool with one optional, fully documented parameter and no output schema, the description is complete. It tells the agent what the tool does, what command it runs, and what data it returns, leaving no ambiguity for selection or invocation.

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

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

The input schema has 100% description coverage for its single optional 'firewall' parameter, so the schema already carries the semantic weight. The description does not need to repeat parameter details.

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

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

The description names a specific verb and resource: retrieving IPSec VPN tunnel status and security associations, and backs it with the exact command executed. This clearly distinguishes it from sibling read-only get_* 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 clearly implies the use case: when an agent needs IPSec VPN tunnel status or security association information. It does not explicitly name alternatives or when-not-to-use, but the resource is specific enough that no sibling tool overlaps.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds '[READ-ONLY]' which merely repeats the annotation, and 'Executes: request license info' hints at an underlying command but adds no meaningful behavioral context such as response format or scope of features covered.

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

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

The description is short and front-loaded with the READ-ONLY tag, and the core purpose is stated in the first sentence. The second sentence, 'Executes: request license info,' adds marginal value and is somewhat redundant with 'retrieves,' but overall there is no wasted material.

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

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

For a simple read-only tool with one optional, fully documented parameter, the description is adequate. It does not describe the return structure, but there is no output schema and the operation is a straightforward status query, so the missing detail is a minor gap rather than a blocking one.

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

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

Schema description coverage is 100%, so the schema fully documents the one optional 'firewall' parameter. The description adds nothing about parameter semantics, but with full schema coverage the baseline of 3 is appropriate.

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

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

The description states a specific verb ('retrieves') and resource ('license status and expiration dates for all features'), making the tool's function unambiguous. However, it does not explicitly distinguish itself from the sibling tool get_license_usage, so an agent may have to inspect further to differentiate them.

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

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

The description implies when to use the tool—whenever license status or expiration dates are needed—but provides no explicit context about when to prefer it over get_license_usage or get_wildfire_status. There are no stated exclusions or alternative routing, so usage guidance is only implicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the underlying command ('show system info') and extraction behavior, which is marginally useful, but no additional behavioral traits like response format or performance characteristics are disclosed.

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

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

Two sentences with no filler. The read-only tag and primary purpose are front-loaded, and the execution detail is concise and relevant.

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

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

The tool is simple (1 optional param, no output schema) and the description lists the returned fields, making the result shape reasonably clear. It could mention the exact output structure or why 'license usage' differs from 'get_licenses', but for the tool's complexity it is mostly 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?

The input schema has 100% description coverage for the single 'firewall' parameter, including optionality semantics. The description adds no extra meaning 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 states a specific verb ('Retrieves') and resource ('license usage information') and lists concrete fields (VM model, serial, capacity tier, mode). It is clear on its own, but it does not explicitly differentiate from the similarly named sibling 'get_licenses'.

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

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

No guidance is provided on when to use this tool versus alternatives such as 'get_licenses' or other read-only system info tools. The description gives no exclusions or contextual conditions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description repeats this with '[READ-ONLY]', adding no new safety information. It does add useful context about the config path and the types of NAT rules contained, but it does not mention pagination, return format, or error behavior. This is similar to the calibration example where annotations cover safety, so the description adds modest but not rich behavioral context.

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

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

Two sentences with no filler. The first sentence front-loads the core purpose, and the second provides a specific config path that adds practical value. Every sentence earns its place.

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

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

For a simple read-only list tool with one optional parameter, annotations already carry the safety profile and the schema fully documents the parameter. The description covers scope and config location. It does not elaborate on return values, but none are expected beyond a list of NAT rules, which is implied. Minor missing guidance about Panorama vs firewall context is more of a usage-guideline gap.

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

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

The input schema has 100% coverage; the single 'firewall' parameter is fully described, including when it is required. The description adds no additional parameter-level detail beyond the schema, which is the expected 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 plus resource: 'Retrieves all NAT policy rules', listing the three rule types (source, destination, bidirectional). It clearly differentiates from siblings like get_security_rules and get_pbf_rules by focusing on the NAT rulebase, and the config path adds additional precision.

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 alternatives. Given the sibling panorama_get_device_group_nat_rules, the description should clarify that get_nat_rules is for firewall-local NAT rules rather than Panorama-based ones, but it does not. The only implied usage is 'when NAT rules are needed'.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read. The description adds the config path as a small extra behavioral detail, but the '[READ-ONLY]' prefix merely repeats the annotation. No return format, pagination, or filtering behavior is disclosed.

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

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

Two short sentences with no filler: the first states the verb and resource, the second gives the config path. The '[READ-ONLY]' tag is redundant with annotations but costs little and aids quick scanning.

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 one optional parameter and no output schema, the description plus schema cover the essential call context. It lacks any hint about the return structure, but the config path and clear scope make the tool usable without more.

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 single 'firewall' parameter is fully documented in the schema, including its source (firewalls.json) and conditional requirement ('Required when multiple firewalls are configured; optional otherwise'). The description adds no parameter-specific guidance, so the baseline of 3 applies.

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

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

The description states the exact resource ('policy-based forwarding (PBF) rules') and expands the acronym, making the tool's function immediately clear. It is distinct from sibling tools like get_security_rules and get_nat_rules by naming PBF specifically.

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 context is clear: this tool retrieves PBF rules, and the config path ('/config/.../rulebase/pbf/rules') further clarifies it reads from the firewall configuration. However, it does not explicitly name alternatives or state when not to use it, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context by identifying the exact config path being read, but it does not disclose return shape, pagination, or any operation-specific behavior beyond the path.

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

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

The description is extremely concise: two sentences, no filler, with the most identifying information ('READ-ONLY', resource name, and config path) front-loaded. Every sentence adds useful 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 simple read-only tool with one optional, fully-documented parameter, the description combined with the schema is nearly complete for invocation. It lacks a note about expected return content, but the tool name and config path provide enough context for an agent to use it correctly.

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

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

Schema description coverage is 100%, and the sole 'firewall' parameter is fully documented in the schema, including when it is required. The description itself adds no parameter-level meaning, but with complete schema coverage the baseline score of 3 is appropriate.

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

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

The description clearly states the operation ('Retrieves QoS policy rules'), naming both the verb and the specific resource. It is easily distinguishable from sibling config getters like get_security_rules or get_pbf_rules, and the config path further disambiguates the exact rule type.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives such as get_config_xpath or other get_*_rules tools. It implies a config-read operation via 'Reads config at', but does not state conditions, exclusions, or alternatives.

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

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

The annotations already mark it read-only and non-destructive; the description adds a '[READ-ONLY]' confirmation and, more valuably, reveals the exact command executed ('show routing route'), giving the agent concrete knowledge of device-side behavior. The description is fully consistent with the annotations — no contradiction.

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

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

Two compact sentences that front-load the purpose and follow with the exact device command. The '[READ-ONLY]' prefix is a minor redundancy with readOnlyHint, but otherwise every element earns its place.

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

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

For a read-only tool with a single optional parameter and no output schema, this is reasonably complete: the agent knows what is retrieved and which command runs. The only notable omission is any indication of the return shape or volume, which would also help differentiate it from get_static_routes.

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 alone fully documents the optional firewall parameter, including when it is required. The description therefore does not need to add parametric detail; it only loosely mirrors the target via 'from the firewall.' 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+resource: 'Retrieves the current routing table from the firewall,' and discloses the underlying device command 'show routing route,' which pins down the exact operation. It does not explicitly contrast itself with the sibling get_static_routes, though the phrase 'routing table' plus the show command makes the distinction largely 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?

Provides no guidance on when to use this tool versus the many get_* siblings, notably get_static_routes, which is the most likely confusable alternative. The agent must infer selection criteria from the tool name alone; the description never states the condition for choosing this tool over alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the config path and clarifies the group-aggregation behavior, which is useful context but not extensive. No contradiction with annotations.

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

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

Two concise sentences with no filler. The read-only flag and core purpose are front-loaded, and the config path provides useful context without bloating the description.

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

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

For a simple one-parameter read-only tool, the description covers purpose, scope via config path, and the single optional parameter is fully documented in the schema. It does not describe return structure, but no output schema exists and the tool is simple enough that the description is largely sufficient.

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

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

Schema description coverage is 100%, and the firewall parameter is already fully documented in the input schema. The description adds no additional parameter-level meaning, so the baseline of 3 applies.

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

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

States a specific verb and resource: 'Retrieves security profile groups that combine multiple security profiles.' The vsys config path hints at firewall-local scope, but it does not explicitly differentiate from the sibling panorama_get_shared_profile_groups, so it is clear but not fully sibling-distinct.

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

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

No guidance on when to use this tool versus alternatives such as get_security_profiles or panorama_get_shared_profile_groups. Usage context is only implied by the name and config path, with no explicit when-to-use or when-not-to-use conditions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with '[READ-ONLY]'. It adds the config path, which gives useful context about where data is read from, but does not mention return format, pagination, or authentication needs. Given the annotation coverage, this is adequate but not extensive.

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

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

The description is a single sentence that front-loads the read-only nature and the resource, then includes the config path. '[READ-ONLY]' slightly duplicates the annotation, but the overall length is compact and every part adds useful 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 one-parameter tool with no output schema, the description plus schema covers the essentials: what is retrieved, where from, and the optional firewall parameter. It does not describe the return structure, but that is not required here, and the tool is simple enough that this description is sufficient for correct invocation.

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

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

Schema description coverage is 100%, and the only parameter 'firewall' is fully documented in the schema, including its source (firewalls.json) and optionality. The description itself adds no parameter-specific meaning, so the baseline score of 3 applies.

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

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

The description states a specific verb ('Retrieves') and resource ('security profiles'), enumerating concrete profile types (antivirus, vulnerability, spyware, URL filtering). It also provides a config path that distinguishes it from siblings like get_security_profile_groups and panorama_get_shared_security_profiles, making the tool's scope unambiguous.

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

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

The description implies usage context through the config path (/config/.../vsys/entry/profiles), indicating it targets firewall-local profiles rather than Panorama shared ones. However, it does not explicitly name alternative tools or state when not to use it, leaving the guidance implicit rather than explicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with '[READ-ONLY]'. It adds the config path detail, which is useful context, but does not disclose other behavioral aspects such as response size or pagination. With annotations covering safety, the bar is lower, but the extra context is minimal.

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

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

The description is two short sentences with no fluff. The primary action is front-loaded, and the config path adds a concrete detail without padding.

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

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

For a simple read-only tool with one well-documented parameter, the description is largely complete. It states the resource and scope, and the lack of an output schema is mitigated by the clear implication that the return is the list of rules. Minor missing context includes any caveats about large responses or how the firewall parameter affects the query, but these are not critical for basic usage.

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

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

The input schema provides a full description of the 'firewall' parameter (including when it is required vs optional). The description adds no additional meaning or syntax beyond what the schema already covers, so it relies on the schema's 100% coverage.

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

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

The description clearly states the action ('Retrieves all security policy rules') and the resource ('security policy rules') with scope ('all'). It distinguishes from siblings like get_security_profiles (different resource) and find_security_rules (which implies search/filter) by emphasizing 'all'.

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

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

The description implies the tool is for retrieving the full rulebase, but it does not explicitly state when to use this instead of alternatives like find_security_rules or when not to use it. The sibling list contains a similar tool, but no direct contrast is provided.

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

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

The description reinforces the read-only annotation with a [READ-ONLY] prefix and adds a concrete config path ('/config/.../vsys/entry/service-group'). This provides useful behavioral context beyond the annotations, though it does not describe return format or pagination.

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 compact sentence communicates the operation, scope, and config path with no wasted words. The read-only marker is front-loaded for immediate safety recognition.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description and annotations are sufficient for an agent to select and invoke it correctly. The lack of return-format detail is a minor gap but not critical for this operation.

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

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

Schema description coverage is 100%, and the single optional 'firewall' parameter is already well documented in the schema. The description adds no additional parameter semantics, but none are needed given the schema's completeness.

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 ('Retrieves') and resource ('service groups'), and clarifies the scope ('all service groups that contain multiple service objects'). It is clearly distinguishable from siblings like get_service_objects, add_service_group, and delete_service_group.

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

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

No guidance is given about when to prefer this tool over alternatives such as get_service_objects or the add/delete service group tools. The description implies a read operation but does not state exclusions or selection criteria.

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

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

Annotations already provide readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing the config path ('/config/.../vsys/entry/service') and emphasizing the read-only nature, giving an agent useful context about what is being accessed.

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

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

The description is two short sentences with no filler. The safety prefix and core purpose are front-loaded, and the config path is a useful addition that earns its place.

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

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

For a simple read-only list operation with one optional parameter and full schema coverage, the description is nearly complete. It could be improved by briefly noting that this returns service objects as opposed to service groups, but nothing critical is missing for making the call.

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

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

The sole parameter 'firewall' has full schema description coverage, including 'Required when multiple firewalls are configured; optional otherwise.' The description adds no additional parameter semantics, but since the schema covers 100% of the parameter meaning, the baseline score of 3 is appropriate.

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

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

The description states a specific verb ('Retrieves'), a clear resource ('all service objects'), and clarifies the domain with 'port/protocol definitions'. This distinguishes it from sibling tools like get_service_groups and get_address_objects by object type and scope.

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

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

The intended use is implied: call this when you need the full list of service objects from the firewall. However, the description does not explicitly contrast it with alternative or related tools such as get_service_groups, nor does it state 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with '[READ-ONLY]'. It adds a config path detail, which provides mild implementation context, but it does not explain return format, pagination, or behavior when no routes exist.

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

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

Two short sentences with no filler. The read-only marker and primary action are front-loaded, making the purpose immediately visible.

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

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

For a simple read-only tool with fully documented optional parameters and no nested objects, the description plus annotations are almost sufficient. The only minor gap is that no return format is described, but the nature of the tool makes this a limited concern.

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 (firewall and virtual_router) are already fully documented in the schema. The description adds no additional meaning beyond referencing the virtual-router config path.

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

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

The description clearly states a specific verb and resource: 'Retrieves static routes from a virtual router.' The mention of static routes distinguishes it from related siblings like get_routing_table, add_static_route, and delete_static_route without ambiguity.

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

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

There is no guidance about when to use this tool versus alternatives, such as get_routing_table for a broader view or the add/delete route tools for modifications. The reader must infer usage from the name and the basic description.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description need not repeat safety. It adds useful context such as 'recent' logs, PanOS log API type=log, filtering, and count limiting. However, it does not disclose details like pagination, log entry structure, or any rate-limiting behavior.

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

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

A single, front-loaded sentence with the READ-ONLY marker first, followed by the core action and key capabilities. There is no fluff or repetition of schema details.

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

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

For a read-only, zero-required-parameter tool with a fully documented schema, the description provides sufficient operational context: source, API type, recency, filtering, and count limiting. It does not describe return format, but no output schema exists and this is a simple log retrieval tool, so the core context is adequately covered.

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 nlogs, query, and firewall with descriptions. The description adds only a general mention of 'filtering by query and limiting result count,' which maps to the schema but does not add deeper semantic meaning beyond it.

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

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

The description clearly states a specific verb and resource: 'Retrieves recent system logs from the firewall using the PanOS log API (type=log).' It also mentions filtering and result count limiting. It does not explicitly distinguish itself from sibling log tools like get_traffic_logs, though the resource name 'system logs' provides implicit differentiation.

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

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

The description implies this tool is for retrieving system logs and has filtering capabilities, but it gives no explicit guidance about when to choose this tool over get_traffic_logs, get_threat_logs, get_config_logs, or get_url_filter_logs. No alternative tools or exclusionary conditions are mentioned.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, and the description adds value beyond them by disclosing the exact underlying command (show system resources) and the data categories returned. The leading [READ-ONLY] marker reinforces the annotations rather than contradicting them. It does not describe the response format, but this is secondary given the safety profile is already declared.

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

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

Two compact sentences carry the safety signal, the purpose, the data dimensions, and the underlying command with zero filler. The most important information is front-loaded.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description names the returned dimensions (CPU, memory, disk) and the command executed. It could clarify the output shape further, but nothing essential for correct selection and invocation 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?

The input schema documents the only parameter (firewall) at 100% coverage, including the condition for when it is required (multiple firewalls configured). The tool description adds no parameter-level detail, but with high schema coverage 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 pairs a specific verb (Retrieves) with a concrete resource (system resource utilization) and enumerates the dimensions covered (CPU, memory, disk usage). This is clearly distinct from sibling get_* tools that target other resources like routing tables or ARP tables, though it does not name an 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?

No guidance is given on when to choose this tool versus alternatives such as get_firewall_info or get_interfaces, and there are no exclusion criteria or prerequisites stated. Usage context is only implicit in the tool name and the schema's note about when the firewall parameter is 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?

It explicitly says it reads config at /config/.../vsys/entry/tag, adding behavioral context beyond the readOnlyHint annotation. It does not discuss auth, rate limits, or pagination, but for a read-only getter those are less critical.

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

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

Two compact sentences with no filler; the read-only marker and config path each earn their place. It is front-loaded with the most important identification of the tool.

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

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

Given a single optional parameter and no output schema, the description is adequate: scope, config path, and read-only nature are covered. It does not state return shape, but for an 'all tags' getter this is predictable.

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 one parameter, firewall, is fully documented in the schema with 100% coverage, including its optionality. The description adds no parameter-level detail, 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 names a specific verb and resource ('Retrieves all tags defined on the firewall') and clarifies scope with the config path. This is distinct from sibling add_tag/delete_tag and the other get_* read 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?

No when-to-use or alternate-tool guidance is given. With many sibling get_* and tag mutation tools, an agent must infer from the name and path when this is the right call.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with a [READ-ONLY] prefix. It adds a useful detail about using the PanOS log API type=log, but does not disclose specifics like time window limits, pagination behavior, or response format. The annotations carry most of the safety disclosure burden.

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

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

Two compact sentences front-load the read-only nature and core purpose, then summarize the main parameter capabilities. There is no fluff or repetition; every phrase adds 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?

Given the simple parameter set and fully covered schema, the description is mostly complete for calling the tool correctly. The only notable gap is clarifying what 'recent' means and whether there are any default time-window constraints, but this is a minor omission for a query-based log fetch.

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 (nlogs, query, firewall) are already fully documented with types, bounds, defaults, and examples. The description adds a brief high-level mention of filtering and result limiting, but does not need to add more since the schema is comprehensive.

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

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

The description clearly states the action (retrieves), the resource (recent threat logs), and the underlying mechanism (PanOS log API type=log). This is specific enough to distinguish it from sibling log-retrieval tools like get_traffic_logs or get_system_logs without needing to inspect 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 scope is implicitly clear: use this tool when threat logs are needed and filtering or count limiting is desired. However, it does not explicitly mention alternatives or when not to use it, which would be valuable given the sibling tools for traffic, system, config, and URL filtering logs.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with '[READ-ONLY]'. It adds useful context about using the PanOS log API and supporting filtering/limiting, but it does not disclose details such as the time window behind 'recent' or the output structure. With annotations covering the safety profile, the extra disclosure is adequate but not rich.

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

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

The description is one tightly written sentence that leads with the read-only marker and the core verb 'Retrieves', followed by the resource and key capabilities. There is no filler or repetition of schema details.

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

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

This is a relatively simple tool with three optional parameters, all fully described in the schema, and annotations already establish the read-only safety profile. The description covers purpose, filtering, and result limiting, which is sufficient for an agent to call it correctly. A minor gap is the absence of any detail about the default/possible time range for 'recent', but this does not block correct invocation.

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

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

Schema description coverage is 100%, so the input schema already documents nlogs, query, and firewall clearly. The description adds only a high-level mention of 'filtering by query and limiting result count', which maps to query and nlogs but does not add meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Retrieves recent traffic logs from the firewall using the PanOS log API (type=log)'. The term 'traffic logs' clearly distinguishes it from sibling log retrieval tools such as get_threat_logs, get_system_logs, and get_url_filter_logs.

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

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

The description provides clear context by specifying that this tool retrieves traffic logs, which is the right category for firewall traffic-related log queries. It does not explicitly name alternative tools for other log types, but the scope is unambiguous enough for an agent to select it appropriately among the sibling log tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's '[READ-ONLY]' prefix merely repeats that. The description adds useful context about the playbook's contents but does not disclose additional behaviors such as authentication needs, rate limits, or output format, though for a read-only retrieval tool these are less critical.

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

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

The description is compact, front-loaded with the read-only nature and primary action, and every clause earns its place. The topic list is long but directly supports the tool's purpose, and there is no filler or repetition.

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

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

For a parameterless, read-only reference tool, the description fully equips an agent: it states what is returned, lists the covered domains, and says when to consult it. No output schema exists, but the description sufficiently conveys the return value's scope without needing a formal 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?

The tool has zero parameters, so the schema description coverage is effectively 100% by vacuity. The description correctly provides no parameter details, and the topic list helps set expectations for what the returned playbook contains. The no-parameter baseline of 4 is appropriate.

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

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

The description names a specific verb ('Returns') and a specific resource ('the troubleshooting playbook'), then enumerates the topics it covers. This clearly distinguishes it from all sibling getters and diagnose tools, which focus on individual data sources or checks.

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

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

The description explicitly says to read it 'when the cause is unclear or before concluding,' giving clear contextual guidance. It does not name alternative tools or state when not to use it, but the intended use is unambiguous.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the config path '/config/predefined/pan-url-categories', which gives useful sourcing context, but it does not mention error behavior, authentication needs, or what happens when no firewall is specified.

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

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

Two short sentences, with the read-only status and core purpose front-loaded. Every word earns its place and there is no filler or repetition.

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

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

This is a simple read-only getter with one optional parameter, a fully documented schema, and annotations covering safety. The description names the config source and the returned resource type. It could mention how it differs from sibling url_category_* tools, but the tool is otherwise complete enough to 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 description coverage is 100%, so the firewall parameter is already fully documented in the schema. The description adds no parameter-level meaning, but it does not need to because the schema carries the burden.

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

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

The description states a specific verb ('Retrieves') and a specific resource ('predefined URL filtering categories') and even names the config path. It is clear what the tool returns, though it does not explicitly differentiate itself from sibling tools like url_category_list, url_category_get, or url_category_find.

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

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

There is no guidance about when to use this tool versus alternatives such as url_category_list, url_category_get, or url_category_find. The '[READ-ONLY]' tag implies safe usage, but the description does not state when this specific getter is preferred.

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

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

Annotations already declare readOnlyHint and destructiveHint, and the description adds a [READ-ONLY] marker and concrete behavioral details: it uses the PanOS log API with type=log&log-type=url and returns URL categories and actions like allow/block/continue/override. This goes beyond the annotation and helps the agent understand what the call does and returns.

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

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

The description is a single focused sentence plus a read-only prefix, front-loading the key safety and purpose information. Every clause adds value: API call type, log subtype, and the output content. No filler or redundant repetition of title or 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 read-only log retrieval tool, the description covers the query mechanism, the specific log stream, and the output semantics. It lacks an explicit statement of time range or response structure, but the schema describes the filtering controls and no output schema exists, so the description is reasonably complete for the tool's simplicity.

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

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

Schema description coverage is 100%: all three parameters (nlogs, query, firewall) have meaningful descriptions. The description itself does not add parameter-specific semantics, but with full schema coverage the parameters are already well documented, matching the baseline of 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?

Description states specific verb+resource: retrieves recent URL filtering logs from a firewall via PanOS log API with log-type=url. It clearly identifies the domain (URL filtering) and output content (URLs and actions), distinguishing it from sibling log tools like traffic or threat logs.

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 context by specifying URL filtering logs and the API log type, but it does not explicitly state when to choose this over get_traffic_logs, get_threat_logs, or get_system_logs. There is no when-not or alternative routing guidance, leaving the agent to infer appropriateness from the tool name and description.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds context about reading a config path, which is useful but does not go beyond the annotation much. There is no contradiction between the 'READ-ONLY' label and the read-only annotations.

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

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

The description is compact: one sentence of purpose and one of the config path. Every part adds information, and the read-only attribute is front-loaded for quick agent recognition.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description adequately explains what is retrieved and where from. It is slightly incomplete in not differentiating itself from the nearby User-ID mapping/group tools, but overall enough for correct invocation.

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

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

The only parameter, 'firewall', already has a fully descriptive schema comment explaining it targets a firewall name and is optional unless multiple firewalls are configured. Since schema description coverage is 100%, the description does not need to add much, and it does not.

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

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

The description clearly states a specific verb ('Retrieves') and a specific resource ('User-ID configuration settings'), and gives concrete detail about scope ('agent configuration and group mapping'). The config path helps distinguish it from read tools focused on live mappings or groups, though it does not explicitly name siblings.

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

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

The description gives no guidance on when to choose this tool over related siblings like get_userid_mappings or get_userid_groups. There is no mention of exclusions, prerequisites, or alternative tools, so an agent must infer appropriate usage solely from the phrase 'configuration settings'.

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

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

Annotations already mark this as read-only and non-destructive, and the description reinforces this with the explicit `[READ-ONLY]` label and the underlying `show user group list` command. This adds behavioral context beyond the structured annotations, making the read-only execution model clear.

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

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

The description is compact and front-loaded: it declares read-only status, states the action, and includes the exact command in two short sentences. Every element earns its place with no redundancy.

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

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

For a simple read-only list operation with one optional parameter and no output schema, the description provides enough to invoke the tool correctly. It could be more complete by noting response format or when to prefer it over sibling User-ID tools, but those are minor gaps given the operation's simplicity.

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

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

Schema description coverage is 100% for the single optional `firewall` parameter, so the schema already fully documents parameters. The description adds no additional parameter-level meaning, which is acceptable under the baseline for high schema coverage.

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

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

The description states a specific verb ('Retrieves') and resource ('user groups known to the firewall via User-ID'), and backs it with the exact CLI command (`show user group list`). It is clear what the tool does, though it does not explicitly contrast itself with sibling tools like `get_userid_mappings` or `get_userid_config`.

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

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

The description gives no guidance on when to use this tool versus related siblings, no mention of prerequisites, and no context about the optional `firewall` parameter being needed when multiple firewalls are configured. Usage is only implied by the tool's basic purpose.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the concrete executed command, 'show user ip-user-mapping all', which reveals the exact backend behavior and the 'all' scope. This goes meaningfully beyond the annotations, though it does not discuss output size or pagination.

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

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

The description is two sentences with no filler. It front-loads the read-only marker, states the action, and includes the exact command—every sentence contributes value.

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

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

For a simple read-only listing tool with one optional parameter fully documented in the schema, the description is sufficient. It states what is returned, the scope, and the underlying command. Minor gaps exist around output shape or potential large result sets, but these are not critical for a tool of this complexity.

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 firewall parameter is already fully documented. The description does not add additional parameter context beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

Description uses a specific verb ('Retrieves') and resource ('IP-to-user mappings from User-ID'), and clarifies scope ('all'). This clearly distinguishes it from related siblings like get_userid_groups and get_userid_config, which concern different User-ID aspects.

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

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

The usage context is implied by the stated purpose—use when you need IP-to-user mappings—but there is no explicit when-to-use or when-not-to-use guidance, and it does not name alternative tools such as userid_lookup or get_userid_config. The description provides no exclusions or alternative routing.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false; the description repeats read-only intent and adds the config source path. It does not disclose output format, pagination, or any other behavioral detail, but for a simple read-only getter the annotation plus source path is adequate.

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

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

One efficient sentence front-loads the read-only nature and the core action. The config path is useful context, though the '[READ-ONLY]' prefix slightly duplicates the annotation.

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

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

For a single-parameter, read-only getter with no output schema, the description is largely sufficient: it identifies the resource and the config location. It could describe the return shape, but the operation's simplicity and annotations compensate.

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 one parameter 'firewall' is already fully documented. The description offers no additional parameter guidance, which is acceptable given the schema baseline of 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 and resource: 'Retrieves VLAN configuration from the firewall.' The config path adds concrete detail. It does not explicitly distinguish itself from sibling get_* tools, but the resource is clear enough.

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 about when to use this tool instead of siblings like get_config, get_interfaces, or get_zones. Usage must be inferred entirely from the tool name and the generic purpose statement.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false; the description reinforces this with '[READ-ONLY]' and adds the execution command. It does not describe output shape or which statistics are returned, but for a simple read-only retrieval the existing coverage is adequate and there is no contradiction.

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

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

The description is short, front-loaded with purpose, and the CLI command adds useful context. The '[READ-ONLY]' prefix is redundant with annotations but minor; overall there is no wasted material.

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

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

For a read-only tool with one optional parameter and no output schema, the description covers what it returns ('status and statistics'), the execution mechanism, and safety. It could be more explicit about which statistics are included, but nothing essential is missing for correct invocation.

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

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

Schema description coverage is 100%, and the schema fully documents the firewall parameter including source file and requirement condition. The description itself adds no parameter detail, so the baseline of 3 applies.

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

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

States a precise verb ('Retrieves') and a specific resource ('WildFire cloud connection status and statistics'), and additionally names the underlying CLI command, 'show wildfire status'. This is enough to distinguish it from sibling status tools like get_ha_status or get_licenses without opening schemas.

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

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

Usage is implied rather than explicit: an agent can infer 'use this when WildFire connection status/stats are needed.' There is no when-not guidance, no mention of alternatives, and no context about when the optional firewall parameter matters, though the schema covers that detail.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with '[READ-ONLY]'. It adds some useful context by pointing to the config path, but does not disclose output format, pagination, or any edge-case behavior, so it only moderately exceeds the annotations.

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

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

The description is very concise, with two short sentences that front-load the purpose and then provide a useful config-path detail. Every sentence earns its place and there is no redundant 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 simple read-only retrieval tool with one optional parameter, the description is largely complete: it states what is retrieved and where the data is read from. It does not describe the return format, but the simplicity of the tool and the explicit read-only annotations reduce the need for additional detail.

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 single 'firewall' parameter is already fully documented in the input schema. The description does not add meaningful detail beyond the schema, so it meets the baseline but does not enhance parameter understanding.

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 ('Retrieves') with a clear resource ('all security zones configured on the firewall'), making the tool's purpose immediately obvious. It also provides the config path, which helps distinguish it from sibling getters like get_vlans or get_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?

No explicit guidance is given about when to use this tool versus sibling tools such as get_vlans or get_routing_table. The usage context is only implied by the resource name and description, with no alternatives or exclusions mentioned.

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

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

The read-only annotation is reinforced by the [READ-ONLY] prefix, and the description adds the underlying CLI command and 'currently connected' temporal semantics. However, it does not disclose output format, pagination behavior, or any operational side effects beyond what the readOnly/destructive annotations already imply.

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

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

The description is a single front-loaded sentence that communicates the read-only nature, the resource, and the optional user filter with no filler. Every part adds signal, and it is easy for an agent to parse.

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

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

For a read-only query tool with four fully documented optional parameters and no output schema, the description is reasonably complete. The main gap is that sibling tools like get_globalprotect_users could overlap in purpose, and the description does not resolve that selection ambiguity or describe what the returned data looks like.

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

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

The input schema has 100% description coverage for all four optional parameters, so the schema carries the parameter-semantic burden. The description only adds a minor hint that the user parameter is optional for filtering by one user, which does not meaningfully extend the schema's documentation.

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

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

The description states a specific action and resource: listing GlobalProtect users currently connected to a gateway firewall, with an optional single-user filter. It is clear and maps to a concrete CLI command, but it does not explicitly differentiate itself from the similarly named sibling get_globalprotect_users, leaving some ambiguity.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives such as get_globalprotect_users or get_active_sessions. The phrase 'optionally for one user' hints at a filtering use case, but there is no when-to-use, when-not-to-use, or alternative tool recommendation.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context: it is explicitly '[READ-ONLY]', it 'never API keys' (a privacy guarantee), and it indicates whether the firewall parameter is required in other tools (a response semantic). This goes beyond the annotations and is helpful, though it does not cover edge cases like empty lists or error responses, so it is not a 5.

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

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

The description is compact and front-loaded with the [READ-ONLY] marker. Every clause adds value: the read-only status, the list purpose, the output contents, the privacy guarantee, and the additional indication about the firewall parameter. No wasted words.

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

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

For a zero-parameter tool with no output schema, the description covers the essential return semantics (names, hosts, no API keys, and the firewall-parameter-required indicator). It does not specify the exact response shape (e.g., field names or types), but given the tool's low complexity and the absence of an output schema, it is sufficiently complete for an agent to invoke 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 input schema has zero properties and the description correctly adds no parameter details. The rule states a baseline of 4 for 0 parameters, and the description does not introduce any conflicting or unnecessary parameter information.

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

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

The description states a specific verb and resource: 'Lists all configured firewall targets.' It also clarifies output contents (names/hosts, no API keys) and a secondary purpose (indicating whether the firewall parameter is required). While the sibling set includes panorama_list_firewalls, the description does not explicitly differentiate local versus Panorama, so it is not a 5; however, the name and content make the purpose 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 implies when to use the tool: to enumerate firewall targets and learn whether the firewall parameter is required for other tools. It does not explicitly name alternatives or state when not to use it (e.g., versus panorama_list_firewalls). It provides a clear functional context but no exclusions, so it earns a 3.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a small behavioral detail by pointing at the config path, but the path is partially elided ('/config/.../log-collector-group') and no other behavior such as response shape or error cases is disclosed.

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

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

The description is two short sentences with no filler or redundant explanation beyond the useful config-path note. It is front-loaded with the primary action and read-only nature.

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 one optional, well-documented parameter, the description conveys the target resource and source location clearly. It would be slightly stronger with a note on the return shape or an explicit distinction from collector-related siblings, but nothing essential is missing for 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?

The single parameter, firewall, is fully documented in the schema with its meaning and optionality, and schema coverage is 100%. The description does not add any additional parameter-level detail, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Retrieves') and resource ('collector group configuration from Panorama'), and adds a config path for extra precision. It does not explicitly contrast with the closely named sibling panorama_get_log_collectors, so it stops short of full sibling differentiation.

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

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

There is no guidance about when to use this tool versus alternatives such as panorama_get_log_collectors or other Panorama getters, and no exclusions are mentioned. The [READ-ONLY] prefix conveys safety but not selection criteria.

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

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

Annotations already mark readOnlyHint=true, and the description adds a concrete execution behavior ('show jobs all') plus explicit READ-ONLY labeling. It does not describe the output shape, but the command disclosure is useful beyond annotation metadata. No contradiction with annotations.

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

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

Two short sentences, front-loaded with the READ-ONLY marker, and every clause adds information: what it retrieves and exactly which command it executes. There is no filler or repetition beyond the safety marker.

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

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

For a simple one-parameter read-only tool, the description and schema are sufficient for an agent to select and invoke it. The lack of an output schema and absence of return-format details are minor gaps, since the command 'show jobs all' anchors expectations.

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 only parameter, firewall, has full schema description coverage at 100%, so the schema carries the semantic load. The description adds no parameter information, which is acceptable at the baseline for high coverage.

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

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

States a specific verb and resource: retrieves status of pending commits in Panorama, and uniquely identifies the underlying command 'show jobs all'. However, it does not explicitly contrast with sibling status tools such as panorama_get_push_status or run_show_command, so differentiation is left 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?

The phrase 'status of pending commits' implies when to use the tool, but no alternatives or exclusions are given. With many sibling getters and status commands, the agent must infer why this tool is preferable to related panorama status and command tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a config path ('/config/readonly/.../device-group') and clarifies the hierarchy focus, which is helpful context. It does not describe return shape or potential absent hierarchy behavior, but this is a simple read 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 short sentences with no filler. The core behavior is front-loaded, and the supplementary config path is directly relevant. Every sentence earns its place.