PasarGuard MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PASARGUARD_MCP_CONFIG | Yes | Path to the PasarGuard panels JSON configuration file. | |
| PASARGUARD_MAIN_PASSWORD | Yes | Password for the 'main' panel, as referenced by password_env in the configuration file. | |
| PASARGUARD_MCP_STATE_DIR | No | Optional directory for local state files (defaults to platform-specific location). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_panelsA | List configured PasarGuard panel profiles without exposing credentials. |
| test_panelC | Authenticate to a panel and return the current admin identity. |
| get_panel_inventoryB | Fetch a compact panel inventory: nodes, cores, hosts, groups, users, and system status. |
| list_panel_resourceC | List one PasarGuard panel resource. Query supports the panel's normal filters/pagination. |
| get_panel_resourceC | Get a node, core, host, group, or user by numeric ID. |
| get_node_realtime_statsC | Get current realtime statistics for a PasarGuard node. |
| get_panel_system_statusC | Get panel system statistics and worker health. |
| plan_create_nodeB | Plan adding a node. Apply only after asking the user to confirm the returned token. |
| plan_update_nodeA | Plan a partial node update; the MCP fetches and preserves the complete current object. |
| plan_update_coreC | Plan a core update. The full current core is merged with patch and restart_nodes is explicit. |
| plan_update_hostA | Plan a partial host update while preserving required fields from the current host. |
| plan_update_groupC | Plan a partial group update. |
| plan_create_coreC | Plan creating a core configuration using the panel's CoreCreate body. |
| plan_create_hostC | Plan creating a subscription host using the panel's CreateHost body. |
| plan_create_groupC | Plan creating a group using the panel's GroupCreate body. |
| plan_create_userC | Plan creating a PasarGuard user. The body follows the panel's UserCreate model. |
| plan_update_userC | Plan a user update through the current ID-based PasarGuard route. |
| plan_delete_resourceB | Plan deleting a panel resource. This is intentionally separate from update tools. |
| plan_node_actionC | Plan a node action that may reconnect, sync, reset usage, or update its core. |
| apply_changeA | Apply one previously planned change after explicit user confirmation. |
| inspect_changeA | Inspect a local plan summary without exposing its stored credentials or full payload. |
| plan_rollbackB | Plan restoring a previously applied update from its local before-snapshot. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 22 tools
Most tools target distinct resource-action pairs (e.g., plan_create_node vs. plan_update_core), and read tools are clearly separated from planning tools. Some ambiguity exists between plan_node_action and plan_update_core since plan_node_action can also update a core, and plan_delete_resource is generic, but descriptions mitigate this.
The naming follows a consistent verb_noun pattern (e.g., plan_create_node, get_panel_inventory, apply_change). Minor inconsistencies include 'list_panel_resource' (singular generic) and 'plan_rollback' not matching the plan_create/update pattern, but overall the convention is predictable.
With 22 tools, the server is on the heavier side, which can be overwhelming but is justified by the breadth of PasarGuard management. The count is within the 'heavy' range (16-25) rather than extreme, so it earns a middle score.
The tool surface covers create, read, update, delete, planning, applying, rollback, and monitoring for core PasarGuard resources. Minor gaps exist, such as no explicit tool to list planned changes or cancel a plan, but these are workarounds via inspect_change and apply_change.