Visual Sentinel MCP Server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VS_API_KEY | No | API key for Visual Sentinel. Required for authenticated tools (monitors, incidents, alerts, etc.). Can also be set as VISUALSENTINEL_API_KEY. | |
| VS_API_BASE | No | Override base URL for testing against a local development instance. | https://visualsentinel.com |
| VISUALSENTINEL_API_KEY | No | Alias for VS_API_KEY. |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| vs_healthA | Check whether Visual Sentinel itself is up. Returns the service health status. No authentication required. |
| vs_dns_checkA | Resolve DNS records (A, AAAA, MX, NS, TXT, CNAME) for a domain using Visual Sentinel's public DNS lookup tool. No authentication required. |
| vs_ssl_checkA | Inspect a TLS/SSL certificate for a hostname: issuer, subject, validity dates, SAN list, key algorithm, and certificate chain. No authentication required. |
| vs_speed_testA | Run a one-shot performance check against a URL: TTFB, total load time, transfer size, status code, and redirect chain. No authentication required. |
| vs_website_checkA | Quick health check for a URL: HTTP status, response time, server header, content snippet, and basic SSL state. No authentication required. |
| vs_monitors_listC | List monitors in the authenticated organization. Optional filters narrow by status, type, or paginate. |
| vs_monitors_getA | Fetch a single monitor by id, including its current status, last check, and configuration. |
| vs_monitors_createB | Create a new monitor. Provide at least name, url, and type. Returns the created monitor including its assigned id. |
| vs_monitors_check_nowA | Trigger an immediate check for a monitor (in addition to its scheduled cadence). Returns the freshly-collected check result. |
| vs_monitors_uptimeB | Fetch the uptime percentage and outage breakdown for a monitor over a window (default last 30 days). |
| vs_incidents_listA | List incidents for the authenticated organization. Filter by status (OPEN/RESOLVED), monitor id, or paginate. |
| vs_incidents_getA | Fetch a single incident with its full check history and root-cause hints. |
| vs_alerts_listA | List alerts for the authenticated organization. Filter by status (UNACKNOWLEDGED/ACKNOWLEDGED/RESOLVED) or paginate. |
| vs_alerts_acknowledgeA | Acknowledge an alert by id. Acknowledgement is recorded with the calling API key's user. |
| vs_status_pages_listA | List public-facing status pages owned by the authenticated organization. |
| vs_servers_listB | List servers (origins) registered in the authenticated organization. |
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 16 tools
Each tool targets a distinct resource or action: alerts, incidents, monitors, servers, status pages, and public checks (DNS, SSL, speed, health). Even similar tools like vs_website_check and vs_speed_test have clearly differentiated scopes (quick health vs. detailed performance).
Tools follow a consistent vs_{resource}_{action} pattern (e.g., vs_alerts_list, vs_monitors_create) with snake_case. Slight inconsistencies: vs_health is just a noun, and vs_monitors_uptime uses a noun instead of a verb, but overall pattern is clear and predictable.
16 tools is well within the expected range for a monitoring service. Each tool serves a distinct purpose covering alerts, incidents, monitors, servers, status pages, and public utilities. No tool feels extraneous or redundant.
The tool set covers core monitoring workflows (list, get, create monitors; list and get incidents; list and acknowledge alerts) but lacks update and delete operations for monitors and incidents. The surface feels slightly incomplete for full lifecycle management.