Skip to main content
Glama
Antxine

PanOS MCP Server

by Antxine
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

diagnose_threat_block

Read-only

Diagnose why a file or threat was blocked by locating the matching log, rule, security profile, existing exceptions, file-blocking rule, and WildFire verdict.

Instructions

[READ-ONLY] Analyzes a threat/file block (antivirus, WildFire, anti-spyware, vulnerability, file blocking, data filtering): finds the log, the rule and the security profile actually applied (profile group resolved), whether an exception for that threat ID ALREADY exists (in the applied profile or elsewhere), the matching file-blocking rule, and the WildFire verdict.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
userNoUser name, with or without domain (e.g. 'jdoe' or 'corp\\jdoe')
periodNoRelative time window on receive_time (default: last-24-hrs)
src_ipNoIP address
filenameNoFile name (substring)
firewallNoPanorama entry from firewalls.json. Optional when a single Panorama is configured.
file_hashNoSHA-256 of the file
threat_idNoNumeric threat ID (e.g. 52020)
incident_timeNoWhen the issue happened, 'YYYY/MM/DD HH:MM' in Panorama's timezone. Searches +/-30 minutes around it instead of 'period'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.30

TDQS

A4.1/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Deploy Server

Other Tools