Beszel MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BESZEL_URL | Yes | The URL of your Beszel/PocketBase instance (e.g., http://localhost:8090) | |
| BESZEL_EMAIL | No | Admin email for authentication | |
| BESZEL_PASSWORD | No | Admin password for authentication |
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
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_systemsB | List all monitored systems in Beszel. Args: page: Page number (default: 1) per_page: Number of results per page (default: 50) filter: PocketBase filter string (e.g., "name ~ 'server'" or "status = 'active'") sort: Sort order (e.g., "-created" for descending by created date) Returns: Dictionary containing paginated list of systems with their status and metadata |
| list_containersB | List all monitored containers in Beszel. Args: page: Page number (default: 1) per_page: Number of results per page (default: 50) filter: PocketBase filter string sort: Sort order Returns: Dictionary containing paginated list of containers running on monitored systems |
| list_alertsB | List all configured alerts in Beszel. Args: page: Page number (default: 1) per_page: Number of results per page (default: 50) filter: PocketBase filter string sort: Sort order Returns: Dictionary containing alert configurations including thresholds and notification settings |
| list_alert_historyA | List alert history in Beszel. Args: page: Page number (default: 1) per_page: Number of results per page (default: 50) filter: PocketBase filter string sort: Sort order (e.g., "-created" for most recent first) Returns: Dictionary containing historical records of triggered alerts |
| query_system_statsB | Query statistics for a specific system. Args: system_id: The system ID to query statistics for start_time: Start time in ISO 8601 format (e.g., '2024-01-01T00:00:00Z') end_time: End time in ISO 8601 format page: Page number (default: 1) per_page: Number of results per page (default: 100) Returns: Dictionary containing time-series data for CPU, memory, disk, and network usage |
| query_container_statsB | Query statistics for a specific container. Args: container_id: The container ID to query statistics for start_time: Start time in ISO 8601 format (e.g., '2024-01-01T00:00:00Z') end_time: End time in ISO 8601 format page: Page number (default: 1) per_page: Number of results per page (default: 100) Returns: Dictionary containing time-series data for container CPU, memory, and network usage |
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 6 tools
Each tool has a clearly distinct purpose with no overlap: list_alert_history retrieves historical records, list_alerts shows configurations, list_containers and list_systems enumerate monitored entities, and query_container_stats/query_system_stats fetch specific time-series data. The descriptions make it unambiguous which tool to use for each task.
All tools follow a consistent verb_noun pattern with snake_case: list_alert_history, list_alerts, list_containers, list_systems, query_container_stats, and query_system_stats. The naming convention is predictable and readable throughout the set.
With 6 tools, this server is well-scoped for monitoring systems and containers, covering listing entities and querying statistics. Each tool earns its place without being too sparse or bloated, fitting typical MCP server ranges.
The toolset provides solid read-only coverage for monitoring: listing alerts, containers, systems, and querying their stats. Minor gaps exist, such as no tools to create/update/delete alerts or containers, but agents can work around this for observation-focused workflows.