Model Context Protocol server for Visual Sentinel: six-layer website monitoring (uptime, performance, SSL, DNS, visual regression, content change) accessible from Claude Desktop, Claude Code, Cline, Continue, and any MCP-compatible client.
Visual Sentinel MCP server has well-structured tool definitions with consistent naming (verb_noun pattern: vs_*), complete input schemas with proper JSON Schema types, and clear descriptions for most tools. However, several critical gaps reduce the score: (1) output schemas are not documented, LLMs cannot predict response structure for downstream chaining; (2) parameter descriptions lack actionable constraints (e.g., enum values for 'status', 'type', 'recordType' are stated in text but not formalized as JSON Schema enums); (3) error handling is absent, no guidance on retryability, user-fixable errors, or recovery paths; (4) no tool annotations (readOnlyHint, destructiveHint) despite clear risk classifications in metadata. The 11 tools average 3.6 parameters with descriptions, meeting baseline (p10=1, p90=8), but descriptions average ~120 chars (below ideal 194-char baseline for production tools). Authentication model is sound (requiresAuth flag), but no permission scopes declared per pattern:scope-declaration.
Resolve DNS records (A, AAAA, MX, NS, TXT, CNAME) for a domain using Visual Sentinel's public DNS lookup tool. No authentication required.
Check whether Visual Sentinel itself is up. Returns the service health status. No authentication required.
List incidents for the authenticated organization. Filter by status (OPEN/RESOLVED), monitor id, or paginate.
Trigger an immediate check for a monitor (in addition to its scheduled cadence). Returns the freshly-collected check result.
Create a new monitor. Provide at least name, url, and type. Returns the created monitor including its assigned id.
Fetch a single monitor by id, including its current status, last check, and configuration.
Output schemas not documented. LLMs cannot predict response structure, breaking tool chaining and forcing exploratory calls. Every tool must declare what fields it returns.
Enum constraints stated in descriptions but not formalized in JSON Schema. 'recordType' lists 'A, AAAA, MX, NS, TXT, CNAME, SOA' as text; should be enum: ['A', 'AAAA', 'MX', 'NS', 'TXT', 'CNAME', 'SOA']. Same for 'status', 'type', 'window'. LLMs cannot parse text constraints reliably.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
List monitors in the authenticated organization. Optional filters narrow by status, type, or paginate.
Fetch the uptime percentage and outage breakdown for a monitor over a window (default last 30 days).
Run a one-shot performance check against a URL: TTFB, total load time, transfer size, status code, and redirect chain. No authentication required.
Inspect a TLS/SSL certificate for a hostname: issuer, subject, validity dates, SAN list, key algorithm, and certificate chain. No authentication required.
Quick health check for a URL: HTTP status, response time, server header, content snippet, and basic SSL state. No authentication required.
No error handling guidance. Tools lack recovery hints (e.g., 'If domain not found, try vs_dns_check with a parent domain'). No categorization of errors as retryable vs user-fixable. Agents cannot self-correct on failures.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Metadata declares vs_monitors_create as WRITE and vs_monitors_check_now as WRITE, but these are not exposed in the MCP tool definition. LLMs cannot infer safety properties.
No permission scopes declared. Tools require VS_API_KEY but do not declare what permissions they need (e.g., 'read:monitors', 'write:monitors'). Prevents least-privilege agent configuration and audit clarity.