Visual Sentinel을 위한 Model Context Protocol 서버로, 가동 시간, 성능, SSL, DNS, 시각적 회귀 및 콘텐츠 변경 감지를 포함한 6계층 웹사이트 모니터링 플랫폼입니다.
Claude Desktop, Claude Code, Cline, Continue 또는 기타 MCP 호환 클라이언트를 Visual Sentinel 계정에 연결하여 AI 어시스턴트가 모니터 목록 조회, 생성, 인시던트 기록 가져오기, 무료 DNS/SSL/속도 확인 실행 및 알림 승인 등을 대신 수행하도록 할 수 있습니다.
npm: @visualsentinel/mcp-server
OpenAPI 사양: https://github.com/VisualSentinel/openapi
호스팅된 API 참조: https://visualsentinel.com/docs
공개 Visual Sentinel API를 아우르는 16가지 도구:
공개 도구 (API 키 불필요)
도구 | 엔드포인트 | 목적 |
|
| 서비스 상태 프로브 |
|
| A / AAAA / MX / NS / TXT / CNAME / SOA 레코드 확인 |
|
| TLS 인증서 검사 (발급자, 유효성, SAN 목록, 체인) |
|
| 일회성 성능 확인 (TTFB, 총 로드 시간, 전송 크기) |
|
| 빠른 HTTP 상태 확인 |
인증 도구 (VS_API_KEY 필요)
도구 | 엔드포인트 | 목적 |
|
| 상태/유형 필터를 포함한 모니터 목록 조회 |
|
| 현재 상태를 포함한 단일 모니터 정보 가져오기 |
|
| 새 모니터 생성 |
|
| 즉시 확인 트리거 |
|
| 24시간/7일/30일/90일/365일 가동 시간 비율 |
|
| 상태 또는 모니터별로 필터링 가능한 인시던트 목록 |
|
| 전체 확인 기록을 포함한 인시던트 정보 가져오기 |
|
| 상태별 알림 목록 조회 |
|
| 알림 승인 |
|
| 공개 상태 페이지 목록 조회 |
|
| 등록된 오리진 서버 목록 조회 |
Related MCP server: Sentinel Monitoring MCP Server
~/Library/Application Support/Claude/claude_desktop_config.json (macOS) 또는 %APPDATA%\Claude\claude_desktop_config.json (Windows)에 추가하세요:
{
"mcpServers": {
"visualsentinel": {
"command": "npx",
"args": ["-y", "@visualsentinel/mcp-server"],
"env": {
"VS_API_KEY": "vs_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
}
}Claude Desktop을 재시작하세요. 도구 메뉴 아래에 16개의 도구가 나타납니다.
claude mcp add visualsentinel \
-- npx -y @visualsentinel/mcp-server그런 다음 Claude Code가 실행되는 셸에서 VS_API_KEY를 내보내세요.
Cline의 MCP 설정에 다음을 추가하세요:
{
"visualsentinel": {
"command": "npx",
"args": ["-y", "@visualsentinel/mcp-server"],
"env": { "VS_API_KEY": "vs_live_..." }
}
}~/.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-server이 서버는 MCP 사양(2025-06-18)에 따라 stdio를 통해 JSON-RPC를 통신합니다.
두 가지 환경 변수가 있으며, 명시된 경우를 제외하고는 모두 선택 사항입니다:
변수 | 기본값 | 목적 |
| (없음) | 11개의 인증 도구에 필수. 공개 도구는 키 없이 작동. https://visualsentinel.com/settings/api-keys 에서 생성 가능. |
|
| 로컬 개발 인스턴스 테스트용으로만 재정의. |
인증이 필요한 도구를 VS_API_KEY 없이 호출하면 서버는 조용히 실패하는 대신 명확한 오류를 반환합니다.
VISUALSENTINEL_API_KEY는 더 긴 이름을 선호하는 클라이언트를 위해 VS_API_KEY의 별칭으로 허용됩니다.
설치 후 AI 어시스턴트에게 다음과 같이 질문해 보세요:
"visualsentinel.com의 SSL 인증서 상태는 어떤가요? 언제 만료되나요?"
"현재 다운된 Visual Sentinel 모니터를 나열해 줘."
"https://shop.example.com에 대해 1분마다 확인하는 새 HTTPS 모니터를 추가해 줘."
"지난 24시간 동안의 인시던트를 보여주고, 모니터 ID clm123에 대한 인시던트를 승인해 줘."
"지난 30일 동안 내 랜딩 페이지의 가동 시간 비율은 얼마인가요?"
"https://example.com/checkout에 대해 속도 테스트를 실행해 줘."
어시스턴트가 적절한 도구를 선택하고 대화 내용에서 인수를 채운 뒤 JSON 응답을 보여줍니다.
API 키는 이 MCP 서버를 실행하는 컴퓨터를 절대 떠나지 않습니다. 요청은 HTTPS를 통해 https://visualsentinel.com으로 직접 전송됩니다.
공개 도구(vs_health, vs_dns_check, vs_ssl_check, vs_speed_test, vs_website_check)는 API 키 없이 작동하지만, 그 결과는 대화 로그를 읽을 수 있는 사람이라면 누구나 볼 수 있습니다. 다른 셸 명령과 동일하게 취급하세요.
유출된 API 키는 https://visualsentinel.com/settings/api-keys 에서 즉시 취소하세요. 취소는 몇 초 내에 적용됩니다.
상태를 변경하는 도구(vs_monitors_create, vs_monitors_check_now, vs_alerts_acknowledge)는 API 키의 역할 기반 권한을 상속받습니다. 읽기 전용 키로는 모니터를 생성할 수 없습니다.
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 --watch프로덕션 API에 대해 로컬에서 스모크 테스트를 수행하려면:
VS_API_KEY=vs_live_... node dist/index.js서버는 stdin/stdout에서 JSON-RPC를 통신합니다. tools/list 요청을 파이프로 전달하여 등록된 도구를 확인하세요.
시맨틱 버전을 따릅니다. 도구 이름이나 필수 인수에 대한 주요 변경 사항은 메이저 버전이 올라갑니다. 새로운 도구나 선택적 인수를 추가하는 것은 마이너 또는 패치 업데이트입니다.
서버의 도구 인터페이스는 https://github.com/VisualSentinel/openapi 에 있는 공개 Visual Sentinel API 사양을 따릅니다. 업스트림 API에 유용한 엔드포인트가 추가되면 이 저장소도 일반적으로 릴리스 내에 업데이트됩니다.
MIT. LICENSE를 참조하세요.
Visual Sentinel API 서비스 자체는 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
