Provides comprehensive management of Palo Alto Networks firewalls through specialized servers for security policy and rule management, system configuration, network objects and address management, and device operations including monitoring, commits, and backups.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Palo Alto Networks MCP Server Suite show me all security rules that allow HTTP and HTTPS traffic"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A comprehensive suite of Model Context Protocol (MCP) servers for managing Palo Alto Networks firewalls and services through a unified API interface.
Related MCP server: Palo Alto Device Server
The Palo Alto Networks MCP Server Suite provides a modular approach to firewall management through specialized servers:
Core Server: Base firewall operations and shared functionality
Policy Server: Security policy and rule management
Config Server: System configuration and settings
Objects Server: Network objects and address management
Device Server: Device operations and monitoring
┌─────────────────┐ ┌──────────────────┐
│ Core Server │◄────┤ Policy Server │
│ │ └──────────────────┘
│ (Base Services)│ ┌──────────────────┐
│ │◄────┤ Config Server │
│ │ └──────────────────┘
│ │ ┌──────────────────┐
│ │◄────┤ Objects Server │
│ │ └──────────────────┘
│ │ ┌──────────────────┐
│ │◄────┤ Device Server │
└────────┬────────┘ └──────────────────┘
│
▼
┌─────────────────┐
│ Palo Alto API │
└─────────────────┘To install Palo Alto Networks MCP Server Suite for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @DynamicEndpoints/paloalto-mcp-server --client claudeClone the repository:
git clone https://github.com/your-org/paloalto-mcp-servers.git
cd paloalto-mcp-serversInstall dependencies for each server:
# Install core server
cd paloalto-server
npm install
# Install policy server
cd ../paloalto-policy-server
npm install
# Install config server
cd ../paloalto-config-server
npm install
# Install objects server
cd ../paloalto-objects-server
npm install
# Install device server
cd ../paloalto-device-server
npm installConfigure environment variables:
# Create .env files in each server directory
PANOS_API_KEY=your-api-key
PANOS_API_BASE_URL=https://your-firewall.example.com/api
# Optional configurations
PANOS_VERIFY_SSL=true
PANOS_TIMEOUT=30000
PANOS_DEBUG=falseBase server providing shared functionality and core operations.
Authentication and session management
API rate limiting and retry logic
Shared utility functions
Error handling framework
const result = await useMcpTool("paloalto-server", "verify_credentials", {
api_key: process.env.PANOS_API_KEY
});
console.log(result.content[0].text); // Authentication statusComprehensive policy and rule management.
get_security_rules
// Get all security rules
const rules = await useMcpTool("paloalto-policy", "get_security_rules", {});
// Get rules with filtering
const webRules = await useMcpTool("paloalto-policy", "get_security_rules", {
filter: {
service: ["http", "https"],
action: "allow"
}
});create_security_rule
// Create a basic security rule
await useMcpTool("paloalto-policy", "create_rule", {
rule_type: "security",
rule_data: {
name: "allow-internal-web",
source: ["internal-network"],
destination: ["web-servers"],
service: ["http", "https"],
action: "allow",
log_setting: "default",
profile_setting: {
group: ["default-protection"]
}
}
});
// Create a more complex rule with zones and applications
await useMcpTool("paloalto-policy", "create_rule", {
rule_type: "security",
rule_data: {
name: "restrict-social-media",
source_zone: ["trust"],
destination_zone: ["untrust"],
source: ["internal-users"],
destination: ["any"],
application: ["facebook-base", "twitter-base"],
service: ["application-default"],
action: "deny",
log_setting: "detailed-logging",
description: "Block social media access"
}
});update_security_rule
// Update an existing rule
await useMcpTool("paloalto-policy", "update_rule", {
rule_type: "security",
rule_name: "allow-internal-web",
rule_data: {
service: ["http", "https", "ssh"],
description: "Updated to allow SSH access"
}
});System configuration and settings management.
// Update DNS settings
await useMcpTool("paloalto-config", "update_network_settings", {
dns_primary: "8.8.8.8",
dns_secondary: "8.8.4.4",
dns_search_domain: "example.com"
});
// Configure interfaces
await useMcpTool("paloalto-config", "configure_interface", {
name: "ethernet1/1",
config: {
mode: "layer3",
ip: ["10.0.1.1/24"],
zone: "trust",
enable: true
}
});Network object and address management.
// Create address objects
await useMcpTool("paloalto-objects", "create_address_object", {
name: "web-server-1",
type: "ip-netmask",
value: "10.0.1.100/32",
description: "Primary web server",
tags: ["production", "web"]
});
// Create address group
await useMcpTool("paloalto-objects", "create_address_group", {
name: "web-servers",
description: "All web servers",
members: ["web-server-1", "web-server-2"],
tags: ["production", "web"]
});
// Create dynamic address group
await useMcpTool("paloalto-objects", "create_dynamic_address_group", {
name: "active-web-servers",
description: "Web servers currently in use",
filter: "tag.production and tag.web and state.up"
});Device operations and monitoring.
// Get device status
const status = await useMcpTool("paloalto-device", "get_device_status", {});
// Commit changes
await useMcpTool("paloalto-device", "commit_changes", {
description: "Updated security policies",
admins: ["admin1"], // Optional: Specify which admin's changes to commit
});
// Backup configuration
await useMcpTool("paloalto-device", "backup_config", {
filename: "backup-2024-01-20.xml",
include_shared: true
});async function deploySecurityPolicy() {
// 1. Create address objects
await useMcpTool("paloalto-objects", "create_address_object", {
name: "internal-subnet",
type: "ip-netmask",
value: "192.168.1.0/24"
});
// 2. Create security rules
await useMcpTool("paloalto-policy", "create_rule", {
rule_type: "security",
rule_data: {
name: "allow-outbound",
source: ["internal-subnet"],
destination: ["any"],
service: ["web-browsing"],
action: "allow"
}
});
// 3. Verify configuration
const rules = await useMcpTool("paloalto-policy", "get_security_rules", {});
// 4. Commit changes
await useMcpTool("paloalto-device", "commit_changes", {
description: "Deployed new security policy"
});
}async function configureHA() {
// 1. Configure HA interfaces
await useMcpTool("paloalto-config", "configure_ha", {
mode: "active-passive",
group: {
id: 1,
description: "Primary HA Group"
},
interfaces: {
ha1: {
port: "ethernet1/3",
ip: "10.0.0.1/24"
},
ha2: {
port: "ethernet1/4",
ip: "10.0.1.1/24"
}
}
});
// 2. Configure HA policy
await useMcpTool("paloalto-config", "configure_ha_policy", {
preemptive: true,
heartbeat_interval: 2000,
heartbeat_threshold: 3
});
// 3. Commit changes
await useMcpTool("paloalto-device", "commit_changes", {
description: "Configured HA settings"
});
}const ruleTemplate = {
base: {
log_setting: "default",
profile_setting: {
group: ["default-protection"]
}
},
web: {
service: ["web-browsing"],
application: ["web-browsing"],
profile_setting: {
group: ["strict-web-protection"]
}
}
};
async function createRuleFromTemplate(type, customData) {
const template = {...ruleTemplate.base, ...ruleTemplate[type]};
await useMcpTool("paloalto-policy", "create_rule", {
rule_type: "security",
rule_data: {...template, ...customData}
});
}async function batchCreateObjects(objects) {
const results = [];
for (const obj of objects) {
try {
const result = await useMcpTool("paloalto-objects", "create_address_object", obj);
results.push({status: "success", name: obj.name});
} catch (error) {
results.push({status: "error", name: obj.name, error: error.message});
}
}
return results;
}API Connection Issues
// Test API connectivity
const status = await useMcpTool("paloalto-server", "test_connection", {
timeout: 5000,
verify_ssl: true
});
if (!status.success) {
console.error(`Connection failed: ${status.error}`);
// Check firewall accessibility
// Verify API key permissions
// Validate SSL certificates
}Rule Conflicts
// Analyze rule conflicts
const analysis = await useMcpTool("paloalto-policy", "analyze_rules", {
rule_type: "security",
checks: ["shadowing", "redundancy", "conflicts"]
});
if (analysis.issues.length > 0) {
console.log("Found rule issues:", analysis.issues);
}Commit Failures
try {
await useMcpTool("paloalto-device", "commit_changes", {
description: "Policy update"
});
} catch (error) {
if (error.code === "ConfigurationLocked") {
// Handle locked configuration
await useMcpTool("paloalto-device", "release_config_lock", {});
} else if (error.code === "ValidationError") {
// Handle validation errors
console.error("Configuration validation failed:", error.details);
}
}Fork the repository
Create a feature branch
git checkout -b feature/new-featureCommit your changes
git commit -m "Add new feature"Push to the branch
git push origin feature/new-featureCreate a Pull Request
MIT License - see LICENSE file for details
Get system information from the Palo Alto firewall
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves information but doesn't specify what type of system information (e.g., hardware status, software versions, network stats), whether it requires authentication, rate limits, or the format of returned data. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple retrieval with no parameters) but lack of annotations and output schema, the description is incomplete. It doesn't explain what information is returned, the data format, or any behavioral aspects like error handling, making it inadequate for an agent to use the tool effectively without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it appropriately avoids mentioning any parameters, maintaining a baseline score of 4 for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get system information') and target resource ('from the Palo Alto firewall'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'list_resources' or 'view_config_node_values', which might also retrieve information from the same system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention what distinguishes it from sibling tools like 'list_resources' or 'view_config_node_values', nor does it specify prerequisites, appropriate contexts, or exclusions for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List resources from a specific category
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Resource category to list | |
| resource_type | Yes | Specific resource type within the category |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'List resources' but doesn't reveal if this is a read-only operation, requires authentication, has rate limits, or what the output format might be. This leaves significant gaps for a tool with parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it front-loaded and easy to parse. However, it's slightly under-specified given the tool's complexity, but it earns high marks for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'resources' entail, how results are returned, or any behavioral traits, leaving the agent with insufficient context for effective 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, with clear documentation for both parameters, including an enum for 'category.' The description adds no additional meaning beyond the schema, such as explaining the relationship between 'category' and 'resource_type' or providing examples. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'List resources from a specific category,' which provides a basic verb ('List') and resource target ('resources'), but it's vague about what 'resources' means in this context and doesn't differentiate from sibling tools like 'get_system_info' or 'view_config_node_values.' It's adequate for minimal understanding but lacks specificity.
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 offers no guidance on when to use this tool versus alternatives like 'get_system_info' or 'view_config_node_values,' nor does it mention prerequisites or exclusions. It implies usage for listing by category but fails to provide context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multi-Move or Multi-Clone the configuration of the Palo Alto firewall
| Name | Required | Description | Default |
|---|---|---|---|
| config_paths | Yes | Paths to the configurations to move or clone | |
| new_location | Yes | New location for the configurations | |
| action | Yes | Action to perform |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Multi-Move or Multi-Clone' but doesn't clarify critical aspects like whether this is a destructive operation (e.g., if 'move' deletes the original), potential side effects, error handling, or performance implications. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the key action and resource, making it easy to grasp quickly. However, it could be slightly more structured by explicitly separating the 'move' and 'clone' options for 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?
Given the complexity of a firewall configuration tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, error handling, and what the tool returns (e.g., success status or error messages). For a mutation tool like this, more context is needed to ensure safe and effective 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?
Schema description coverage is 100%, so the schema already documents all parameters ('config_paths', 'new_location', 'action') with clear descriptions. The description adds no additional meaning beyond what the schema provides, such as explaining path formats or the implications of 'move' vs. 'clone'. Thus, it meets the baseline but doesn't 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 clearly states the action ('Multi-Move or Multi-Clone') and the resource ('configuration of the Palo Alto firewall'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'view_config_node_values' or 'list_resources', which might also involve configuration operations, leaving some ambiguity about when this specific tool should be used versus others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing specific permissions or existing configurations, or when to choose 'move' vs. 'clone' actions. Without this context, users might struggle to apply it correctly in different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View configuration node values for XPath on the Palo Alto firewall
| Name | Required | Description | Default |
|---|---|---|---|
| xpath | Yes | XPath to the configuration node |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'view,' implying a read-only operation, but doesn't specify whether this requires authentication, has rate limits, or what the output format looks like (e.g., structured data or raw text). This leaves significant gaps in understanding how the tool behaves.
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 that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple tool, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of interacting with a firewall configuration and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'configuration node values' entail, how results are returned, or any error conditions, leaving the agent with insufficient context for reliable 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, with the 'xpath' parameter documented as 'XPath to the configuration node.' The description adds no additional meaning beyond this, such as examples of valid XPath formats or common use cases. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('view') and target ('configuration node values for XPath on the Palo Alto firewall'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_system_info' or 'list_resources', which might also retrieve information from the firewall.
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. The description lacks context about prerequisites, such as needing specific permissions or connectivity to the firewall, and doesn't mention any exclusions or preferred scenarios for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_system_infolist_resourcesmulti_move_clone_configurationview_config_node_valuesScored across 4 tools
The tools have distinct primary functions (system info, listing, configuration operations, viewing values), but some overlap exists: 'list_resources' and 'view_config_node_values' both involve retrieving configuration data, which could cause confusion about which to use for specific queries. Descriptions help clarify, but boundaries are not perfectly clear.
Naming is inconsistent with mixed conventions: 'get_system_info' and 'list_resources' use verb_noun patterns, while 'multi_move_clone_configuration' is a verbose compound name without clear structure, and 'view_config_node_values' uses a different verb style. This lack of pattern makes the set less predictable and harder to navigate.
With 4 tools, the count is borderline for a server suite focused on Palo Alto Networks firewall management. It feels thin for covering a comprehensive domain like firewall configuration and monitoring, potentially missing operations like update, delete, or specific resource management, but it's not extremely mismatched.
There are significant gaps in the tool surface for firewall management. While tools exist for getting info, listing, moving/cloning, and viewing values, there's no coverage for creating, updating, or deleting configurations or resources, which are core operations in this domain. This incompleteness will likely cause agent failures in full workflows.
Deploy and manage Edge Network cloud: sites, VMs, storage, DNS, Shield, Assist. Agent self-signup.
Manage products, orders, customers, inventory, and store configuration
Authenticated MCP server for ClearPolicy policy and compliance workflows.
MCP Server for agents to onboard, pay, and provision services autonomously with InFlow
