Netskope NPA MCP Server
A Model Context Protocol (MCP) server for managing Netskope Network Private Access (NPA) infrastructure through Large Language Models (LLMs).
Warning
Still lots of work needs to be done for all 50 tools to be operational, i strongly advise against using this with any production environment
Demonstration
https://github.com/johnneerdael/netskope-mcp/raw/refs/heads/main/demo.movβ
Installation
Option 1: NPM Package
Install the package using npm:
npm install @johnneerdael/netskope-mcp
Option 2: Local Development
Clone the repository and install dependencies:
git clone https://github.com/johnneerdael/netskope-mcp.git
cd netskope-mcp
npm install
npm run build
MCP Configuration
Add the following configuration to your MCP settings file:
Windows with WSL
For NPM installation:
{
"mcpServers": {
"netskope-mcp": {
"command": "wsl.exe",
"args": [
"bash",
"-c",
"source ~/.nvm/nvm.sh && NETSKOPE_BASE_URL=https://your-tenant.goskope.com NETSKOPE_API_KEY=your-token npx -y @johnneerdael/netskope-mcp"
]
}
}
}
For local development:
{
"mcpServers": {
"netskope-mcp": {
"command": "wsl.exe",
"args": [
"bash",
"-c",
"cd /path/to/netskope-mcp && NETSKOPE_BASE_URL=https://your-tenant.goskope.com NETSKOPE_API_KEY=your-token node dist/cli.js"
]
}
}
}
Linux and macOS
For NPM installation:
{
"mcpServers": {
"netskope-mcp": {
"command": "npx",
"args": ["-y", "@johnneerdael/netskope-mcp"],
"env": {
"NETSKOPE_BASE_URL": "https://your-tenant.goskope.com",
"NETSKOPE_API_KEY": "your-token"
}
}
}
}
For local development:
{
"mcpServers": {
"netskope-mcp": {
"command": "node",
"args": ["dist/cli.js"],
"cwd": "/path/to/netskope-mcp",
"env": {
"NETSKOPE_BASE_URL": "https://your-tenant.goskope.com",
"NETSKOPE_API_KEY": "your-token"
}
}
}
}
Environment Variables
The Netskope NPA MCP Server requires the following environment variables to be configured for proper operation:
Required Variables
-
NETSKOPE_BASE_URL
- Description: The base URL of your Netskope tenant
- Format: Full URL including protocol
- Example:
https://your-tenant.goskope.com
- Usage: Used for all API communications with your Netskope tenant
- Note: Must be the complete tenant URL without any path components
-
NETSKOPE_API_KEY
- Description: API token for authentication with Netskope services
- Format: String token from Netskope admin console
- Example:
030f31f7d57fd94834af57a3edc4bbda
- Usage: Required for authenticating all API requests
- Security Note: Keep this token secure and never commit it to version control
Configuration Examples
Development Environment
export NETSKOPE_BASE_URL="https://dev-tenant.goskope.com"
export NETSKOPE_API_KEY="your-development-token"
Production Environment
export NETSKOPE_BASE_URL="https://prod-tenant.goskope.com"
export NETSKOPE_API_KEY="your-production-token"
AlertsTools
-
getAlertConfig
- Description: Retrieves the current alert configuration settings for publishers, including notification preferences for various events such as upgrades and connection status changes.
- Required Parameters: None
- Response Schema:
{ adminUsers: string[], // Array of admin user emails to notify eventTypes: string[], // Array of event types to monitor selectedUsers: string // Additional users to notify }
- Event Types:
UPGRADE_WILL_START
: Notification before a publisher upgrade beginsUPGRADE_STARTED
: Notification when upgrade process initiatesUPGRADE_SUCCEEDED
: Notification upon successful upgrade completionUPGRADE_FAILED
: Notification if upgrade process failsCONNECTION_FAILED
: Notification when publisher connection issues occur
- Usage Examples:
- βCheck which administrators are configured to receive upgrade notifications: Use
getAlertConfig
to return the current list of admin users and their notification preferences.β - βVerify the alert configuration before a planned maintenance window: Use
getAlertConfig
to ensure the right team members will be notified of upgrade events.β - βAudit the publisher monitoring setup: Use
getAlertConfig
to show which critical events are being tracked and who receives notifications.β
- βCheck which administrators are configured to receive upgrade notifications: Use
-
updateAlertConfig
- Description: Updates the alert configuration settings for publishers, allowing customization of notification preferences for various system events including upgrades and connection status changes.
- Required Parameters:
{ adminUsers: string[], // Array of admin user emails to receive notifications eventTypes: string[], // Array of event types to monitor selectedUsers: string // Additional users to receive notifications }
- Response Schema: Same as getAlertConfig
- Usage Examples:
- βConfigure notifications: Update alert settings to ensure critical events are properly monitored.β
- βModify recipients: Adjust the list of administrators who receive specific types of alerts.β
- βEvent selection: Customize which event types trigger notifications for different user groups.β
LocalBrokerTools
-
listLocalBrokers
- Description: Lists all configured local brokers in your Netskope environment. Local brokers are used for on-premises Zero Trust Network Access (ZTNA) scenarios where end-users connect to a Local Broker instead of a Cloud Broker to access private applications hosted on-premises.
- Required Parameters: None
- Optional Parameters:
fields
: Array of specific fields to return in the response
- Response Schema:
{ status: 'success' | 'not found', total: number, data: Array<{ id: number, // Unique identifier for the local broker name: string, // Display name of the local broker common_name: string, // Common name used for broker identification registered: boolean // Registration status of the broker }> }
- Usage Examples:
- βMonitor your local broker deployment by listing your local brokers to get an overview of all registered brokers and their current status.β
- βVerify high availability setup: Check if you have multiple local brokers configured per site by reviewing the list of deployed brokers.β
- βAudit broker registration: List all local brokers to identify any unregistered instances that need attention.β
-
createLocalBroker
- Description: Creates a new local broker instance for handling on-premises ZTNA traffic. This is typically used when setting up new sites or expanding capacity for existing locations.
- Required Parameters:
{ name: string // Name for the new local broker }
- Response Schema:
{ status: 'success' | 'not found', data: { id: number, // Assigned unique identifier name: string, // Configured broker name common_name: string, // Assigned common name registered: boolean // Initial registration status } }
- Usage Examples:
- βDeploy a new site: Create a local broker twice to ensure high availability for a new office location.β
- βExpand capacity: Add additional local brokers to handle increased on-premises traffic by creating new broker instances.β
- βInitialize HA setup: Create multiple local brokers with descriptive names indicating their site and role.β
-
getLocalBroker
- Description: Retrieves detailed information about a specific local broker by its ID. Use this to monitor the status and configuration of individual broker instances.
- Required Parameters:
id
: Numeric identifier of the local broker to retrieve
- Response Schema:
{ status: 'success' | 'not found', data: { id: number, // Broker's unique identifier name: string, // Broker's display name common_name: string, // Broker's common name registered: boolean // Current registration status } }
- Usage Examples:
- βCheck broker health: Retrieve specific broker details to verify its registration status and configuration.β
- βTroubleshoot connectivity: Get detailed information about a broker thatβs experiencing issues.β
- βVerify deployment: Confirm the successful creation of a new broker by retrieving its details.β
-
updateLocalBroker
- Description: Updates the configuration of an existing local broker. This allows you to modify broker settings such as its name while maintaining its identity and connections.
- Required Parameters:
{ id: number, // Identifier of broker to update name: string // New name for the broker }
- Response Schema:
{ status: 'success' | 'not found', data: { id: number, // Broker's identifier name: string, // Updated broker name common_name: string, // Broker's common name registered: boolean // Current registration status } }
- Usage Examples:
- βRename for clarity: Update a brokerβs name to better reflect its location or role in your infrastructure.β
- βStandardize naming: Modify broker names to follow updated naming conventions across your organization.β
- βUpdate HA pair: Adjust broker names to clearly indicate primary and secondary roles.β
-
deleteLocalBroker
- Description: Removes a local broker from your Netskope configuration. Use this when decommissioning brokers or cleaning up unused instances.
- Required Parameters:
id
: Numeric identifier of the local broker to delete
- Response Schema:
{ status: 'success' | 'not found' }
- Usage Examples:
- βDecommission old brokers: Remove brokers that are no longer needed or have been replaced.β
- βClean up test instances: Delete temporary brokers created for testing purposes.β
- βSite consolidation: Remove brokers from decommissioned locations while maintaining service at active sites.β
-
getBrokerConfig
- Description: Retrieves the global configuration settings for local brokers, including hostname configurations that affect all broker instances.
- Required Parameters: None
- Response Schema:
{ status: 'success' | 'not found', data: { hostname: string // Global hostname configuration } }
- Usage Examples:
- βReview global settings: Check the current hostname configuration affecting all local brokers.β
- βPrepare for changes: Verify existing configuration before planning updates.β
- βAudit configuration: Ensure hostname settings align with your network architecture.β
-
updateBrokerConfig
- Description: Updates the global configuration settings for all local brokers, allowing you to modify system-wide broker behavior.
- Required Parameters:
{ hostname: string // New hostname configuration }
- Response Schema:
{ status: 'success' | 'not found', data: { hostname: string // Updated hostname configuration } }
- Usage Examples:
- βModify global settings: Update the hostname configuration to reflect network changes.β
- βInfrastructure updates: Adjust broker configurations to accommodate new networking requirements.β
- βStandardize setup: Ensure consistent hostname configuration across all broker instances.β
-
generateLocalBrokerRegistrationToken
- Description: Generates a new registration token for a specific local broker, enabling secure registration with the Netskope management plane.
- Required Parameters:
id
: Numeric identifier of the local broker
- Response Schema:
{ status: 'success' | 'not found', data: { token: string // Generated registration token } }
- Usage Examples:
- βSecure new broker: Generate a token to safely register a newly deployed local broker.β
- βRe-register broker: Create a new token when needing to re-establish broker registration.β
- βToken rotation: Generate new registration tokens as part of security maintenance.β
PolicyTools
-
listRules
- Description: Lists all policy rules configured in your Netskope Private Access environment. These rules define access controls for private applications using Zero Trust Network Access (ZTNA) principles.
- Required Parameters: None
- Optional Parameters:
fields
: Array of specific fields to returnfilter
: Filter criteria for the ruleslimit
: Maximum number of rules to returnoffset
: Number of rules to skipsortby
: Field to sort bysortorder
: Sort direction (βascβ or βdescβ)
- Response Schema:
{ data: { rules: Array<{ id: number, name: string, description?: string, enabled: boolean, action: 'allow' | 'block', policy_group_id: number, priority: number, conditions: Array<{ type: 'private_app' | 'user' | 'group' | 'organization_unit' | 'location' | 'device', operator: 'in' | 'not_in' | 'equals' | 'not_equals' | 'contains' | 'not_contains' | 'starts_with' | 'ends_with', value: string | string[] | number | number[] }>, created_at: string, updated_at: string }> }, status: 'success' | 'error', total: number }
- Usage Examples:
- βAudit access policies to review all configured rules and their conditions to ensure proper access controls.β
- βPrioritize rules: List rules sorted by priority to understand the order of policy evaluation and identify potential conflicts.β
- βFilter specific policies: Retrieve rules related to specific applications or user groups using the filter parameter.β
-
getRule
- Description: Retrieves detailed information about a specific policy rule by its ID. Use this to examine individual rule configurations and conditions.
- Required Parameters:
id
: Numeric identifier of the policy rule
- Optional Parameters:
fields
: Array of specific fields to return
- Response Schema:
{ data: { id: number, name: string, description?: string, enabled: boolean, action: 'allow' | 'block', policy_group_id: number, priority: number, conditions: Array<{ type: 'private_app' | 'user' | 'group' | 'organization_unit' | 'location' | 'device', operator: 'in' | 'not_in' | 'equals' | 'not_equals' | 'contains' | 'not_contains' | 'starts_with' | 'ends_with', value: string | string[] | number | number[] }>, created_at: string, updated_at: string }, status: 'success' | 'error' }
- Usage Examples:
- βTroubleshoot access issues: Examine specific rule details to understand why access might be blocked or allowed.β
- βVerify rule conditions: Check the exact conditions configured for a critical access policy.β
- βReview rule history: Check creation and update timestamps to track policy changes.β
-
createRule
- Description: Creates a new policy rule to control access to private applications. Rules can be based on various conditions including user identity, device status, and location.
- Required Parameters:
{ name: string, // Rule name description?: string, // Optional rule description enabled: boolean, // Rule status action: 'allow' | 'block', // Access action policy_group_id: number, // Associated policy group priority: number, // Rule priority conditions: Array<{ type: 'private_app' | 'user' | 'group' | 'organization_unit' | 'location' | 'device', operator: 'in' | 'not_in' | 'equals' | 'not_equals' | 'contains' | 'not_contains' | 'starts_with' | 'ends_with', value: string | string[] | number | number[] }> }
- Usage Examples:
- βImplement least privilege access: Create rules that grant access only to specific applications based on user roles and device status.β
- βSet up location-based policies: Define rules that restrict access based on user location for compliance requirements.β
- βConfigure group-based access: Create rules that allow specific user groups to access designated private applications.β
-
updateRule
- Description: Updates an existing policy ruleβs configuration. Use this to modify access controls, conditions, or rule properties.
- Required Parameters:
id
: Numeric identifier of the rule to updatedata
: Updated rule configuration following the same schema as create_rule
- Response Schema:
{ data: { // Updated rule details (same as get_rule response) }, status: 'success' | 'error' }
- Usage Examples:
- βAdjust access conditions: Modify rule conditions to accommodate new security requirements or organizational changes.β
- βUpdate rule priority: Change a ruleβs priority to ensure proper policy evaluation order.β
- βEnable/disable rules: Toggle rule status during maintenance or when implementing policy changes.β
-
deleteRule
- Description: Removes a policy rule from your configuration. Use with caution as this permanently removes the access control policy.
- Required Parameters:
id
: Numeric identifier of the rule to delete
- Response Schema:
{ status: 'success' | 'error' }
- Usage Examples:
- βClean up obsolete policies: Remove rules that are no longer needed or have been superseded by new policies.β
- βPolicy consolidation: Delete redundant rules after merging policy configurations.β
- βRemove temporary rules: Clean up temporary access policies created for specific projects or maintenance.β
PrivateAppsTools
-
createPrivateApp
- Description: Creates a new private application in your Netskope environment. This allows you to define and configure applications that will be accessible through your Zero Trust Network Access (ZTNA) infrastructure.
- Required Parameters:
{ app_name: string, // Name of the private application host: string, // Host address of the application clientless_access: boolean, // Enable clientless access is_user_portal_app: boolean, // Show in user portal protocols: Array<{ port: string, // Port number type: 'tcp' | 'udp' // Protocol type }>, publisher_tags?: Array<{ // Optional publisher tags tag_name: string }>, publishers: Array<{ // Associated publishers publisher_id: string, publisher_name: string }>, trust_self_signed_certs: boolean, // Trust self-signed certificates use_publisher_dns: boolean, // Use publisher DNS allow_unauthenticated_cors?: boolean, // Optional CORS settings allow_uri_bypass?: boolean, // Optional URI bypass bypass_uris?: string[], // Optional bypass URIs real_host?: string, // Optional real host app_option?: Record<string, unknown> // Additional options }
- Response Schema:
{ data: { allow_unauthenticated_cors: boolean, allow_uri_bypass: boolean, uribypass_header_value: string, bypass_uris: string[], app_option: Record<string, unknown>, clientless_access: boolean, host: string, id: number, is_user_portal_app: boolean, name: string, protocols: Array<{ ports: string[], type: string }>, real_host: string, service_publisher_assignments: Array<{ primary: boolean, publisher_id: number, publisher_name: string, reachability: { error_code: number, error_string: string, reachable: boolean }, service_id: number }>, tags: Array<{ tag_id: number, tag_name: string }>, trust_self_signed_certs: boolean, use_publisher_dns: boolean }, status: 'success' | 'not found' }
- Usage Examples:
- βDeploy internal application: Create a private app definition for an internal web service with specific protocol and security settings.β
- βConfigure high availability: Set up a private application with multiple publishers for redundancy.β
- βEnable secure access: Create a private app with strict security settings and specific bypass rules.β
-
updatePrivateApp
- Description: Updates the configuration of an existing private application, allowing modification of access settings, protocols, and security parameters.
- Required Parameters:
{ id: number, // Application ID // All other fields same as create_private_app }
- Response Schema: Same as create_private_app
- Usage Examples:
- βModify security settings: Update certificate trust settings and CORS configuration for enhanced security.β
- βAdjust access parameters: Update protocols or bypass rules to accommodate changing requirements.β
- βPublisher reassignment: Modify the list of publishers handling the application traffic.β
-
deletePrivateApp
- Description: Removes a private application from your Netskope configuration. This action permanently removes the application definition and associated access controls.
- Required Parameters:
id
: Numeric identifier of the private application
- Response Schema:
{ status: number, result: string }
- Usage Examples:
- βDecommission service: Remove a private application that is no longer in use.β
- βClean up test apps: Delete temporary applications used for testing.β
- βRemove deprecated services: Clean up old application definitions during infrastructure updates.β
-
getPrivateApp
- Description: Retrieves detailed configuration information about a specific private application.
- Required Parameters:
id
: Numeric identifier of the private application
- Response Schema: Same as create_private_app response
- Usage Examples:
- βAudit configuration: Review detailed settings of a private application for compliance checks.β
- βTroubleshoot access: Examine application configuration to resolve connectivity issues.β
- βVerify settings: Confirm proper configuration after making changes to the application.β
-
listPrivateApps
- Description: Retrieves a list of all configured private applications with their configurations.
- Required Parameters: None
- Optional Parameters:
fields
: Specific fields to returnfilter
: Filter criteriaquery
: Search querylimit
: Maximum number of resultsoffset
: Number of results to skip
- Response Schema:
{ data: Array<{ // Same fields as get_private_app response }>, status: 'success' | 'not found', total: number }
- Usage Examples:
- βInventory applications: Get a complete list of all private applications for audit purposes.β
- βFilter by criteria: Search for applications with specific configurations or tags.β
- βPaginated review: Retrieve applications in manageable chunks for large deployments.β
-
getPrivateAppTags
- Description: Retrieves all tags associated with private applications, useful for organizing and categorizing applications.
- Required Parameters: None
- Optional Parameters:
query
: Search query for tagslimit
: Maximum number of tagsoffset
: Number of tags to skip
- Response Schema:
{ data: Array<{ tag_id: number, tag_name: string }>, status: 'success' | 'not found' }
- Usage Examples:
- βList categories: Retrieve all tags to understand application categorization.β
- βSearch tags: Find specific tags matching certain criteria.β
- βTag inventory: Review all available tags for standardization purposes.β
-
createPrivateAppTags
- Description: Associates new tags with a private application for better organization and management.
- Required Parameters:
id
: Application identifiertags
: Array of tag objects
- Usage Examples:
- βCategorize apps: Add organizational tags to group related applications.β
- βEnvironment labeling: Tag applications based on their deployment environment.β
- βTeam assignment: Add tags to indicate which team owns or manages the application.β
-
updatePrivateAppTags
- Description: Updates the tags associated with one or more private applications.
- Required Parameters:
ids
: Array of application identifierstags
: Array of updated tag objects
- Usage Examples:
- βBulk tag update: Modify tags for multiple applications simultaneously.β
- βTag standardization: Update tags to conform to new naming conventions.β
- βOwnership changes: Update tags to reflect new team assignments.β
-
updatePrivateAppPublishers
- Description: Updates the publisher assignments for private applications, controlling which publishers handle application traffic.
- Required Parameters:
{ private_app_ids: string[], // Application IDs publisher_ids: string[] // Publisher IDs }
- Usage Examples:
- βLoad balancing: Distribute application traffic across multiple publishers.β
- βPublisher migration: Move applications to new or different publishers.β
- βHA configuration: Add backup publishers for high availability.β
-
deletePrivateAppPublishers
- Description: Removes publisher assignments from private applications.
- Required Parameters:
{ private_app_ids: string[], // Application IDs publisher_ids: string[] // Publisher IDs to remove }
- Usage Examples:
- βPublisher decommission: Remove old publishers from application configurations.β
- βClean up assignments: Remove unnecessary publisher assignments.β
- βReconfigure routing: Remove publishers during traffic flow updates.β
-
getDiscoverySettings
- Description: Retrieves the current discovery settings for private applications, which control how applications are discovered and monitored.
- Required Parameters: None
- Usage Examples:
- βReview discovery: Check current application discovery configuration.β
- βAudit settings: Verify discovery parameters for compliance.β
- βMonitor configuration: Examine how applications are being discovered and tracked.β
-
getPolicyInUse
- Description: Retrieves the active policies associated with specified private applications.
- Required Parameters:
ids
: Array of application identifiers
- Usage Examples:
- βPolicy audit: Review which policies are affecting specific applications.β
- βAccess control review: Verify policy assignments for security compliance.β
- βTroubleshoot access: Check policies when investigating access issues.β
PublishersTools
-
listPublishers
- Description: Lists all publishers configured in your Netskope environment. Publishers are the components that handle private application traffic and require proper management for optimal performance.
- Required Parameters: None
- Optional Parameters:
fields
: Specific fields to return in the response
- Response Schema:
{ data: { publishers: Array<{ apps_count: number, assessment: { ca_certs_status: { hashes: string[], last_modified: number }, eee_support: boolean, hdd_free: string, hdd_total: string, ip_address: string, latency: number, version: string }, capabilities: { DTLS: boolean, EEE: boolean, auto_upgrade: boolean, nwa_ba: boolean, pull_nsconfig: { orgkey_exist: boolean, orguri_exist: boolean } }, common_name: string, connected_apps: string[], id: number, lbrokerconnect: boolean, name: string, publisher_upgrade_profiles_id: number, registered: boolean, status: 'connected' | 'not registered', stitcher_id: number, sticher_pop: string, upgrade_request: boolean, upgrade_status: { upstat: string } }> }, status: 'success' | 'not found', total: number }
- Usage Examples:
- βMonitor deployment: List all publishers to check their connection status and capabilities.β
- βAudit configuration: Review publisher settings and associated applications.β
- βCapacity planning: Check the number of apps and load across publishers.β
-
getPublisher
- Description: Retrieves detailed information about a specific publisher, including its configuration, status, and capabilities.
- Required Parameters:
id
: Numeric identifier of the publisher
- Response Schema: Same as individual publisher in list_publishers response
- Usage Examples:
- βHealth check: Get detailed status information for a specific publisher.β
- βTroubleshoot connectivity: Examine publisher capabilities and connection status.β
- βVersion verification: Check publisher version and upgrade status.β
-
createPublisher
- Description: Creates a new publisher instance in your Netskope environment.
- Required Parameters:
{ name: string, // Publisher name lbrokerconnect?: boolean, // Optional local broker connection publisher_upgrade_profiles_id?: number // Optional upgrade profile assignment }
- Response Schema: Same as get_publisher response
- Usage Examples:
- βDeploy new publisher: Create a publisher for a new data center location.β
- βExpand capacity: Add publishers to handle increased application traffic.β
- βConfigure HA: Create additional publishers for high availability setup.β
-
patchPublisher
- Description: Partially updates a publisherβs configuration, allowing modification of specific settings while maintaining others.
- Required Parameters:
{ name: string, // Publisher name id?: number, // Optional publisher ID lbrokerconnect?: boolean, // Optional local broker connection publisher_upgrade_profiles_id?: number // Optional upgrade profile assignment }
- Response Schema: Same as get_publisher response
- Usage Examples:
- βUpdate name: Change publisher name to match new naming convention.β
- βModify connection: Update local broker connection settings.β
- βAssign profile: Link publisher to an upgrade profile.β
-
updatePublisher
- Description: Performs a complete update of a publisherβs configuration, replacing all settings with the provided values.
- Required Parameters:
{ id: number, // Publisher ID name: string, // Publisher name lbrokerconnect?: boolean, // Optional local broker connection tags?: Array<{ // Optional tags tag_id: number, tag_name: string }> }
- Response Schema: Same as get_publisher response
- Usage Examples:
- βFull reconfiguration: Update all publisher settings at once.β
- βTag management: Update publisher tags and configuration together.β
- βReset settings: Replace existing configuration with new values.β
-
deletePublisher
- Description: Removes a publisher from your Netskope configuration. Use with caution as this affects application access.
- Required Parameters:
id
: Numeric identifier of the publisher to delete
- Response Schema:
{ status: 'success' | 'error' }
- Usage Examples:
- βDecommission publisher: Remove a publisher thatβs being retired.β
- βClean up test instances: Delete publishers used for testing.β
- βRemove unused: Clean up publishers that are no longer needed.β
-
bulkUpgradePublishers
- Description: Initiates upgrades for multiple publishers simultaneously.
- Required Parameters:
{ publishers: { apply: { upgrade_request: boolean // Whether to request upgrade }, id: string[] // Array of publisher IDs } }
- Response Schema:
{ data: { publishers: Array<PublisherResponse> }, status: 'success' | 'not found' }
- Usage Examples:
- βMass upgrade: Upgrade all publishers in a specific region.β
- βStaged rollout: Upgrade a subset of publishers at once.β
- βEmergency patching: Apply critical updates to multiple publishers.β
-
getReleases
- Description: Retrieves information about available publisher releases.
- Required Parameters: None
- Response Schema:
{ data: Array<{ docker_tag: string, is_recommended: boolean, release_type: 'Beta' | 'Latest' | 'Latest-1' | 'Latest-2', version: string }>, status: 'success' | 'not found' }
- Usage Examples:
- βVersion planning: Check available releases for upgrade planning.β
- βRelease tracking: Monitor new versions and recommendations.β
- βCompatibility check: Verify release types before upgrading.β
-
getPrivateApps
- Description: Retrieves the list of private applications associated with a specific publisher.
- Required Parameters:
publisherId
: Numeric identifier of the publisher
- Response Schema: Application-specific response
- Usage Examples:
- βApp inventory: List all applications handled by a publisher.β
- βLoad assessment: Check number and type of apps on a publisher.β
- βMigration planning: Review apps before moving to a different publisher.β
-
generatePublisherRegistrationToken
- Description: Creates a new registration token for a publisher, enabling secure registration with the Netskope control plane.
- Required Parameters:
publisherId
: Numeric identifier of the publisher
- Response Schema:
{ data: { token: string // Registration token }, status: string }
- Usage Examples:
- βInitial setup: Generate token for new publisher registration.β
- βRe-registration: Create new token for publisher reconnection.β
- βSecurity refresh: Rotate registration tokens periodically.β
UpgradeProfileTools
-
listUpgradeProfiles
- Description: Lists all upgrade profiles configured in your Netskope environment. Upgrade profiles define when and how publisher upgrades are performed.
- Required Parameters: None
- Response Schema:
{ data: { upgrade_profiles: Array<{ id: number, external_id: number, name: string, docker_tag: string, enabled: boolean, frequency: string, // Cron format: minute hour day * DAY_OF_WEEK timezone: string, // Standard timezone identifier release_type: 'Beta' | 'Latest' | 'Latest-1' | 'Latest-2', created_at: string, updated_at: string, next_update_time?: number, num_associated_publisher: number, upgrading_stage?: number, will_start?: boolean }> }, status: 'success' | 'not found', total: number }
- Usage Examples:
- βReview upgrade schedules: List all profiles to understand when different publishers are scheduled for upgrades.β
- βAudit configurations: Check all upgrade profiles for consistency in settings and schedules.β
- βMonitor upgrade status: View which profiles are actively upgrading or scheduled for updates.β
-
getUpgradeProfile
- Description: Retrieves detailed information about a specific upgrade profile, including its schedule and configuration.
- Required Parameters:
id
: Numeric identifier of the upgrade profile
- Response Schema: Same as individual profile in list_upgrade_profiles
- Usage Examples:
- βVerify settings: Check specific profile configuration before an upgrade window.β
- βTroubleshoot upgrades: Examine profile details when investigating upgrade issues.β
- βMonitor progress: Track the status of an ongoing upgrade process.β
-
createUpgradeProfile
- Description: Creates a new upgrade profile to manage automated publisher upgrades. Profiles control when and how updates are applied to publishers.
- Required Parameters:
{ name: string, // Profile name enabled: boolean, // Profile status docker_tag: string, // Docker image tag for upgrade frequency: string, // Cron schedule format timezone: string, // Timezone for schedule release_type: 'Beta' | 'Latest' | 'Latest-1' | 'Latest-2' }
- Usage Examples:
- βSchedule maintenance: Create a profile for regular off-hours upgrades.β
- βBeta testing: Set up a profile for testing new releases on selected publishers.β
- βRegional updates: Create profiles aligned with different timezone maintenance windows.β
-
updateUpgradeProfile
- Description: Updates an existing upgrade profileβs configuration, allowing modification of schedule, release type, and other settings.
- Required Parameters:
id
: Profile identifierdata
: Updated profile configuration (same schema as create_upgrade_profile)
- Response Schema:
{ data: { // Updated profile details (same as get_upgrade_profile response) }, status: 'success' | 'not found' }
- Usage Examples:
- βAdjust schedule: Modify upgrade timing to better align with maintenance windows.β
- βChange release track: Update profile to use a different release type.β
- βEnable/disable upgrades: Toggle profile status during change freeze periods.β
-
deleteUpgradeProfile
- Description: Removes an upgrade profile from your configuration. Use with caution as this affects automated upgrade scheduling.
- Required Parameters:
id
: Numeric identifier of the profile to delete
- Response Schema:
{ status: 'success' | 'not found' }
- Usage Examples:
- βRemove obsolete profiles: Clean up unused upgrade configurations.β
- βProfile consolidation: Delete redundant profiles after consolidating upgrade schedules.β
- βClean up test profiles: Remove temporary profiles used for upgrade testing.β
SteeringTools
-
updatePublisherAssociation
- Description: Updates the association between private applications and publishers, allowing you to modify which publishers handle specific application traffic.
- Required Parameters:
{ private_app_ids: string[], // Array of private application IDs publisher_ids: string[] // Array of publisher IDs }
- Response Schema:
{ status: 'success' | 'error', data: { private_app_ids: string[], publisher_ids: string[] } }
- Usage Examples:
- βReassign publishers: Update which publishers handle specific private applications.β
- βLoad distribution: Modify publisher assignments for better traffic distribution.β
- βHA configuration: Set up multiple publishers for application redundancy.β
-
deletePublisherAssociation
- Description: Removes associations between private applications and publishers, effectively stopping those publishers from handling the applicationsβ traffic.
- Required Parameters:
{ private_app_ids: string[], // Array of private application IDs publisher_ids: string[] // Array of publisher IDs to remove }
- Response Schema: Same as update_publisher_association
- Usage Examples:
- βRemove associations: Stop specific publishers from handling certain applications.β
- βClean up configuration: Remove unnecessary publisher assignments.β
- βPrepare for decommission: Remove applications before retiring a publisher.β
-
getUserDiagnostics
- Description: Retrieves diagnostic information about user access to private applications, helping troubleshoot connectivity issues.
- Required Parameters: None
- Response Schema:
{ status: 'success' | 'error', data: { user_id: string, diagnostics: Array<{ private_app_id: string, private_app_name: string, publisher_id: string, publisher_name: string, status: string, timestamp: string }> } }
- Usage Examples:
- βAccess troubleshooting: Investigate user connectivity issues to private applications.β
- βAudit access patterns: Review which publishers users are connecting through.β
- βMonitor performance: Check connection status and timing for user access.β
-
getDeviceDiagnostics
- Description: Retrieves diagnostic information about device access to specific private applications.
- Required Parameters:
deviceId
: Device identifierprivateAppId
: Private application identifier
- Response Schema:
{ status: 'success' | 'error', data: { device_id: string, private_app_id: string, diagnostics: Array<{ publisher_id: string, publisher_name: string, status: string, timestamp: string }> } }
- Usage Examples:
- βDevice troubleshooting: Investigate specific device connectivity issues.β
- βApplication access: Check device-specific access to private applications.β
- βConnection history: Review device connection patterns and status.β
ValidationTools
-
validateName
- Description: Validates names for various resources (publishers, private apps, policies, etc.) to ensure they meet naming requirements.
- Required Parameters:
{ resourceType: 'publisher' | 'private_app' | 'policy' | 'policy_group' | 'upgrade_profile', name: string, tagType?: 'publisher' | 'private_app' }
- Response Schema:
{ status: 'success' | 'error', data: { valid: boolean, message?: string } }
- Usage Examples:
- βName validation: Check if a proposed resource name meets requirements.β
- βTag verification: Validate tag names before creation.β
- βPolicy naming: Ensure policy names follow conventions.β
-
validateResource
- Description: Validates complete resource configurations before creation or update operations.
- Required Parameters:
{ resourceType: 'publisher' | 'private_app' | 'policy' | 'policy_group' | 'upgrade_profile', data: { name: string, // Additional resource-specific fields } }
- Response Schema:
{ status: 'success' | 'error', data: { valid: boolean, errors?: string[] } }
- Usage Examples:
- βConfiguration validation: Verify resource settings before creation.β
- βUpdate verification: Validate changes before applying updates.β
- βCompliance check: Ensure resources meet required standards.β
-
searchResources
- Description: Searches for publishers or private applications based on specified criteria.
- Required Parameters:
{ resourceType: 'publishers' | 'private_apps', query: string }
- Response Schema: Resource-specific response format
- Usage Examples:
- βResource search: Find resources matching specific criteria.β
- βPublisher lookup: Search for publishers by name or attributes.β
- βApplication discovery: Find private apps matching search terms.β