Model Context Protocol server for Visual Sentinel, the six-layer website monitoring platform: uptime, performance, SSL, DNS, visual regression, and content change detection.
Connect Claude Desktop, Claude Code, Cline, Continue, or any MCP-compatible client to your Visual Sentinel account so an AI assistant can list monitors, create them, fetch incident history, run free DNS / SSL / speed checks, and acknowledge alerts on your behalf.
npm: @visualsentinel/mcp-server
OpenAPI spec: https://github.com/VisualSentinel/openapi
Get an API key: https://visualsentinel.com/settings/api-keys
Hosted API reference: https://visualsentinel.com/docs
16 tools spanning the public Visual Sentinel API:
Public tools (no API key required)
Tool | Endpoint | Purpose |
|
| Service health probe |
|
| Resolve A / AAAA / MX / NS / TXT / CNAME / SOA records |
|
| Inspect TLS certificate (issuer, validity, SAN list, chain) |
|
| One-shot performance check (TTFB, total load, transfer size) |
|
| Quick HTTP health check |
Authenticated tools (require VS_API_KEY)
Tool | Endpoint | Purpose |
|
| List monitors with optional status / type filters |
|
| Fetch a single monitor with current status |
|
| Create a new monitor |
|
| Trigger an immediate check |
|
| Uptime percentage over 24h / 7d / 30d / 90d / 365d |
|
| List incidents, filterable by status or monitor |
|
| Fetch an incident with full check history |
|
| List alerts by status |
|
| Acknowledge an alert |
|
| List your public status pages |
|
| List registered origin servers |
Related MCP server: Sentinel Monitoring MCP Server
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"visualsentinel": {
"command": "npx",
"args": ["-y", "@visualsentinel/mcp-server"],
"env": {
"VS_API_KEY": "vs_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
}
}Restart Claude Desktop. The 16 tools appear under the tools menu.
claude mcp add visualsentinel \
-- npx -y @visualsentinel/mcp-serverThen export VS_API_KEY in the shell where Claude Code runs.
In Cline's MCP settings, add:
{
"visualsentinel": {
"command": "npx",
"args": ["-y", "@visualsentinel/mcp-server"],
"env": { "VS_API_KEY": "vs_live_..." }
}
}In ~/.continue/config.json:
{
"mcpServers": [
{
"name": "visualsentinel",
"command": "npx",
"args": ["-y", "@visualsentinel/mcp-server"],
"env": { "VS_API_KEY": "vs_live_..." }
}
]
}VS_API_KEY=vs_live_xxx npx -y @visualsentinel/mcp-serverThe server speaks JSON-RPC over stdio per the MCP specification (2025-06-18).
Two environment variables, both optional except in the noted cases:
Variable | Default | Purpose |
| (none) | Required for the 11 authenticated tools. Public tools work without it. Generate at https://visualsentinel.com/settings/api-keys. |
|
| Override only for testing against a local development instance. |
If a tool that needs auth is called without VS_API_KEY, the server returns a clear error rather than silently failing.
VISUALSENTINEL_API_KEY is accepted as an alias for VS_API_KEY for clients that prefer the longer name.
After installation, ask the AI assistant things like:
"What's the SSL certificate situation on visualsentinel.com? When does it expire?"
"List my Visual Sentinel monitors that are currently down."
"Add a new HTTPS monitor for https://shop.example.com checking every minute."
"Show me incidents from the last 24 hours and acknowledge the ones for monitor-id clm123."
"What's the uptime percentage for my landing page over the last 30 days?"
"Run a speed test on https://example.com/checkout."
The assistant chooses the appropriate tool, fills in arguments from the conversation, and shows the JSON response.
Your API key never leaves the machine running this MCP server. Requests go directly to https://visualsentinel.com over HTTPS.
Public tools (vs_health, vs_dns_check, vs_ssl_check, vs_speed_test, vs_website_check) work without an API key, but their results are visible to anyone who can read your conversation logs. Treat them like any other shell-out.
Revoke a leaked API key immediately at https://visualsentinel.com/settings/api-keys. Revocation takes effect within seconds.
Tools that mutate state (vs_monitors_create, vs_monitors_check_now, vs_alerts_acknowledge) inherit your API key's role-based permissions. A read-only key cannot create monitors.
git clone https://github.com/VisualSentinel/mcp-server.git
cd mcp-server
npm install
npm run build # tsup, output to dist/
npm run lint # tsc --noEmit
npm run dev # tsup --watchTo smoke-test locally against the production API:
VS_API_KEY=vs_live_... node dist/index.jsThe server speaks JSON-RPC on stdin / stdout. Pipe in a tools/list request to see the registered tools.
Semantic versioning. Breaking changes to tool names or required arguments get a major bump. Adding new tools or new optional arguments is a minor or patch.
The server's tool surface tracks the public Visual Sentinel API spec at https://github.com/VisualSentinel/openapi. When the upstream API gains a useful endpoint, this repository typically catches up within a release.
MIT. See LICENSE.
The Visual Sentinel API service itself is governed by https://visualsentinel.com/terms.
Acknowledge an alert by id. Acknowledgement is recorded with the calling API key's user.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Alert id. | |
| note | No | Optional acknowledgement note (visible in alert history). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It mentions that acknowledgement is recorded with the calling API key's user, adding some behavioral context. However, it lacks details on effects like state changes or undo capabilities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences, front-loading the primary action and adding one behavioral detail without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters and no output schema. The description covers the main purpose and one behavioral aspect but omits response details and prerequisites, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters. The description adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Acknowledge an alert by id,' which is a specific verb+resource combination. It distinguishes itself from siblings like vs_alerts_list by focusing on the acknowledgement action rather than listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when an alert needs acknowledgment) but provides no explicit guidance on when not to use or alternatives, though the sibling list offers some context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List alerts for the authenticated organization. Filter by status (UNACKNOWLEDGED/ACKNOWLEDGED/RESOLVED) or paginate.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | UNACKNOWLEDGED, ACKNOWLEDGED, or RESOLVED. | |
| page | No | ||
| limit | No | Default 50, max 200. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It describes a read operation ('list alerts') but does not disclose other behavioral traits like rate limits, authentication requirements, or whether the result is paginated. Minimal but acceptable for a simple list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no unnecessary words. Front-loaded with the primary action and parameters. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, no output schema, no annotations), the description provides enough context to understand basic usage. However, it omits details about return structure or ordering, which would be helpful for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds context for the status parameter (listing the enum values) and mentions pagination, which complements the schema's 67% coverage. However, it does not explain the 'page' parameter explicitly, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists alerts for the authenticated organization, with specific filtering options (status values) and pagination. It distinguishes from sibling tools like vs_alerts_acknowledge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to list alerts) but does not provide explicit guidance on when not to use it or how it compares to alternatives such as vs_alerts_acknowledge. No exclusions or context on prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve DNS records (A, AAAA, MX, NS, TXT, CNAME) for a domain using Visual Sentinel's public DNS lookup tool. No authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to resolve, e.g. example.com (without protocol). | |
| recordType | No | Optional: limit to one record type. One of: A, AAAA, MX, NS, TXT, CNAME, SOA. Default: all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states the tool is a 'public DNS lookup tool' and that no authentication is needed, which implies a read-only operation. However, it does not mention rate limits, caching, or error handling. Given the simplicity of DNS lookups, this is minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that are front-loaded with the main purpose and record types. Every word adds value, and there is no unnecessary information. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple DNS lookup tool with no output schema, the description covers the core functionality and record types. It lacks details on potential errors (e.g., invalid domain, timeout) or the format of the response, but given the low complexity, it is mostly complete. A 4 is appropriate as it could mention response format or limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already describes both parameters adequately. The description adds no additional meaning beyond what the schema provides (e.g., the list of record types is present in both). Thus, it meets the baseline for a well-documented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Resolve DNS records'), the resource ('a domain'), and lists specific record types (A, AAAA, MX, NS, TXT, CNAME). This differentiates it from siblings like vs_ssl_check and vs_website_check, which focus on SSL and website status respectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'No authentication required,' which provides some context but does not explain when to use this tool vs. alternatives (e.g., vs_website_check for HTTP availability, vs_ssl_check for certificate checks). There is no explicit when-not or when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether Visual Sentinel itself is up. Returns the service health status. No authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it is a health check (read-only) and requires no authentication. Lacks return format details, but acceptable for a simple endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no waste. Front-loaded with purpose and key detail (no auth).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully sufficient for a parameterless health check with no output schema. No missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. Description adds nothing beyond schema, but baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool checks if Visual Sentinel is up and returns health status. Distinguishes from sibling tools (alerts, DNS, etc.) by focusing on the service itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly notes no authentication required, implying ease of use. Does not mention when not to use or alternatives, but context makes it obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single incident with its full check history and root-cause hints.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Incident id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It indicates a read operation ('Fetch'), but does not disclose any behavioral traits such as authorization requirements, rate limits, or potential errors. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded with the verb and resource, earning its place by providing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (single ID parameter, read operation), the description adequately covers the return value context ('full check history and root-cause hints') which is critical since no output schema exists. It is complete for a basic fetch tool, though it could mention error handling or rate limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter 'id' with its own description. The tool description adds context about the return value but does not enhance the parameter's meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and identifies the resource as 'a single incident' with details 'full check history and root-cause hints'. This clearly distinguishes it from sibling tools like vs_incidents_list which lists multiple incidents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a single incident with detailed history is needed, but it does not explicitly state when to use this tool vs alternatives like vs_incidents_list. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List incidents for the authenticated organization. Filter by status (OPEN/RESOLVED), monitor id, or paginate.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | OPEN or RESOLVED. | |
| monitorId | No | Filter to one monitor. | |
| page | No | ||
| limit | No | Default 50, max 200. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals the operation is read-only (list) and scoped to the authenticated organization, but does not disclose authentication requirements, rate limits, or side effects beyond the implied non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the primary action and then lists filters efficiently. Every word serves a purpose with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain the response format, pagination behavior, or error conditions. It only covers input filters, leaving the agent uninformed about what the tool returns and how to interpret the output, which is a significant gap for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (75%), and the description mostly echoes schema descriptions for status, monitorId, and limit. It adds the pagination concept but does not provide new meaning beyond what the schema already conveys, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists incidents for the authenticated organization, using a specific verb+resource. It distinguishes from siblings like vs_incidents_get (single incident) and vs_alerts_list (different resource) by focusing on list behavior and available filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (listing incidents with filters) but does not explicitly state when to use this tool versus alternatives like vs_incidents_get or vs_alerts_list, nor does it provide when-not or prerequisite conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger an immediate check for a monitor (in addition to its scheduled cadence). Returns the freshly-collected check result.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Monitor id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Indicates mutation (trigger check) and synchronous return of result, but lacks details on side effects, error handling, or rate limits. No annotations provided to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with 15 words, no fluff. Efficiently conveys the core purpose and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple tool with one param and no output schema, description adequately covers action and return. Could mention potential error states but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with a clear description of the 'id' parameter. Description adds no additional semantic information beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states action (trigger immediate check), resource (monitor), and return value (freshly-collected check result). Distinguishes from siblings by specifying 'in addition to its scheduled cadence'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context for on-demand checks beyond scheduled cadence, but does not explicitly state when to use vs alternatives like vs_monitors_get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new monitor. Provide at least name, url, and type. Returns the created monitor including its assigned id.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Display name for the monitor. | |
| url | Yes | Full URL to monitor (or hostname for PING/PORT/DNS/SSL). | |
| type | Yes | Monitor type: HTTP, HTTPS, KEYWORD, PING, PORT, DNS, SSL, VISUAL, CONTENT, API, GRAPHQL, WEBSOCKET. | |
| interval | No | Check interval in seconds (60, 300, 600, 1800, 3600). | |
| timeout | No | Per-check timeout in seconds (default 30). | |
| method | No | HTTP method for HTTP/HTTPS monitors (default GET). | |
| keyword | No | Keyword to assert for KEYWORD monitors. | |
| port | No | TCP port for PORT monitors. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states that it creates a monitor and returns an object with an ID. It does not disclose permissions, idempotency, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences that front-load the action and required parameters. No unnecessary words or redundancies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no annotations, and no output schema, the description is too minimal. It does not explain error conditions, how to use optional parameters like interval or timeout, or what the returned object contains beyond the ID. More context is needed for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 8 parameters. The description adds no extra meaning beyond 'Provide at least name, url, and type.' Since schema coverage is high, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new monitor' with required parameters name, url, and type, and mentions it returns the created monitor with its ID. This distinguishes it from sibling tools like vs_monitors_list or vs_monitors_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: only the required parameters. It does not specify when to use this tool versus alternatives, nor mention any prerequisites or exclusions. No context about when not to use it is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single monitor by id, including its current status, last check, and configuration.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Monitor id (cuid). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It accurately describes the tool as a read operation that returns monitor details, which is sufficient for a simple fetch. No behavioral omissions or contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the core purpose and included information without any extraneous words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description is complete: it states the action, the unique identifier, and the fields returned. No additional context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the single parameter 'id' is described in the schema as 'Monitor id (cuid).' The description does not add any additional meaning or clarification beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Fetch a single monitor by id', and specifies what is included (status, last check, configuration). This distinguishes it from siblings like vs_monitors_list (which fetches all monitors) and vs_monitors_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing details of a specific monitor, but does not explicitly mention when not to use it or suggest alternatives among siblings. The context is clear but lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List monitors in the authenticated organization. Optional filters narrow by status, type, or paginate.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter: UP, DOWN, PAUSED, MAINTENANCE. | |
| type | No | Filter by monitor type: HTTP, HTTPS, KEYWORD, PING, PORT, DNS, SSL, VISUAL, CONTENT, API, GRAPHQL, WEBSOCKET. | |
| page | No | Page number (default 1). | |
| limit | No | Items per page (default 50, max 200). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description adds minimal behavioral context. It does not disclose authentication details (beyond 'authenticated organization'), rate limits, or pagination behavior beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) and front-loaded with the main action. It is not verbose, though it could include a bit more context without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description does not describe the return value or format. For a list tool, it lacks details on what fields are returned or how to handle results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description summarizes filters (status, type, paginate) but adds no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List monitors in the authenticated organization' with specific verb and resource. It mentions optional filters but does not differentiate from sibling tools like 'vs_monitors_get' or 'vs_monitors_create'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only implies usage with optional filters but does not specify prerequisites or exclude scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the uptime percentage and outage breakdown for a monitor over a window (default last 30 days).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Monitor id. | |
| window | No | Window: 24h, 7d, 30d, 90d, 365d. Default 30d. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility. It only states that the tool fetches data, implying a read operation, but fails to disclose any potential side effects, rate limits, permission requirements, or response size. Minimal behavioral insight is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 14 words, tightly focused on the core functionality. It is front-loaded and contains no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description adequately hints at return values (uptime percentage and outage breakdown). It covers the essential purpose and default behavior. However, it could mention read-only nature or data source to be more complete, which keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minor value by linking the window parameter to the default value ('default last 30 days'), but the schema already specifies this. No additional semantic context for the id parameter is given beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and clearly identifies the resource 'uptime percentage and outage breakdown for a monitor'. It also mentions the default window, which distinguishes it from sibling tools like vs_monitors_get (full details) and vs_monitors_list (list of monitors).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives (e.g., vs_monitors_get for detailed monitor info, vs_monitors_check_now for immediate check). No exclusions or context are given, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List servers (origins) registered in the authenticated organization.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No | Default 50. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries all burden for behavioral disclosure. It lacks details on pagination behavior, rate limits, ordering, or any side effects, making it insufficient for a clear understanding of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it is arguably too short for a list operation that could benefit from more detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 simple parameters, no output schema), the description is somewhat complete but lacks pagination details or filtering options. It is minimal but adequate for a basic list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: only 'limit' has a description ('Default 50'), while 'page' has no description. The tool description adds no additional meaning beyond the schema, failing to compensate for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List servers' and specifies the resource 'servers (origins)' and scope 'in the authenticated organization'. This distinguishes it from sibling list tools like vs_alerts_list and vs_monitors_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no context on pagination or filtering. It only states the action without usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a one-shot performance check against a URL: TTFB, total load time, transfer size, status code, and redirect chain. No authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL to test, including protocol (https://...). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the check is one-shot, lists output metrics, and confirms no auth needed. With no annotations, it covers basic behavioral traits but could be more explicit about being read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence with a bullet list front-loading the key information. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description fully explains purpose, inputs, and outputs. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description for the URL parameter is clear, but adds no additional context beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it runs a one-shot performance check on a URL and lists the specific metrics returned (TTFB, load time, etc.), distinguishing it from sibling tools like vs_dns_check or vs_health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions no authentication required, which is helpful, but does not explicitly state when to use vs alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect a TLS/SSL certificate for a hostname: issuer, subject, validity dates, SAN list, key algorithm, and certificate chain. No authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | Hostname to inspect, e.g. example.com (without protocol). | |
| port | No | TCP port. Default 443. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses that no authentication is required, indicating a public read operation. However, it does not mention rate limits, data caching, or any potential side effects, which could strengthen transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose and key details (list of inspected attributes and auth requirement). No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema, the description compensates by listing the exact attributes inspected (issuer, subject, validity dates, SAN list, key algorithm, certificate chain). This sufficiently informs the agent about the output structure and scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% with clear descriptions for 'host' and 'port'. The description does not add new semantic details beyond the schema; it merely repeats the concept of hostname inspection. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Inspect a TLS/SSL certificate for a hostname' and enumerates specific items (issuer, subject, validity dates, SAN list, key algorithm, certificate chain). It is specific and distinct from sibling tools which cover alerts, DNS, health, incidents, monitors, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'No authentication required,' implying it can be used without credentials, but does not provide explicit guidance on when to use versus alternatives or any when-not-to conditions. Since it is the only SSL-related tool, context is clear but exclusionary advice is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List public-facing status pages owned by the authenticated organization.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies a read-only operation ('List') and scopes results to the authenticated organization's public-facing pages. However, it does not explicitly state safety, idempotency, or authorization requirements beyond authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is front-loaded and efficiently communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description adequately covers what the tool does. However, it could mention what happens if no status pages exist or if the organization has no authenticated access, but the simplicity of the tool makes this minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters and 100% schema description coverage (trivially). The description adds no parameter info, which is acceptable given no parameters exist. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List' and the resource 'public-facing status pages owned by the authenticated organization'. It is specific and distinguishes this tool from sibling tools like alerts, incidents, or monitors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as vs_incidents_list or vs_monitors_list. The description does not include exclusions or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quick health check for a URL: HTTP status, response time, server header, content snippet, and basic SSL state. No authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL to test, including protocol (https://...). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It notes no authentication required and lists outputs, but does not mention rate limits, timeouts, or error handling behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Highly concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description adequately describes inputs and outputs. Could add return format or error behavior, but sufficient given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the single parameter with description; the tool's description adds context that URL must include protocol, enhancing the schema's guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a quick health check for a URL, listing specific outputs (HTTP status, response time, etc.). It distinguishes from siblings like vs_dns_check and vs_ssl_check by focusing on general health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indicates quick health check usage and that no authentication is needed. Lacks explicit when-not-to-use or alternatives, but context from sibling tools implies its role among more specific checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0vs_alerts_acknowledgevs_alerts_listvs_dns_checkvs_healthvs_incidents_getvs_incidents_listvs_monitors_check_nowvs_monitors_createvs_monitors_getvs_monitors_listvs_monitors_uptimevs_servers_listvs_speed_testvs_ssl_checkvs_status_pages_listvs_website_checkEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Uptime, SSL, DNS and domain monitoring you can talk to from Claude or any MCP client.
Free anonymous website, DNS, email and TLS checks, plus read-only access to your monitors.
Uptime, API and server monitoring with outages, reporting, on-call and status pages.
Uptime monitoring with 127 tools across 23 protocols. Tag filtering + Code Mode.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/VisualSentinel/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
