Vantaj Uptime MCP
Server Details
Uptime and website monitoring for AI agents. Query monitor status, incidents, heartbeats, domain expiry, and status pages in your Vantaj Uptime workspace.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.9/5 across 13 of 13 tools scored.
Each tool targets a distinct resource or action: monitors, incidents, maintenance windows, domains, heartbeats, projects, and status pages. Even list_monitors and list_heartbeats are differentiated by the type of monitor, and descriptions clarify the purpose.
All tools follow a consistent verb_noun pattern in snake_case (e.g., create_monitor, list_projects, pause_monitor). No mixed conventions or irregular naming.
With 13 tools covering project management, monitor operations, incidents, maintenance, domains, heartbeats, and status pages, the count is well-scoped for an uptime monitoring service. Each tool serves a clear purpose without unnecessary overlap.
The tool set provides create, read, and update operations for monitors, and list/get for other resources, but lacks any delete functionality (e.g., delete_monitor, delete_incident). This is a notable gap that may force agents into workarounds.
Available Tools
13 toolscreate_maintenance_windowCreate maintenance windowAInspect
Schedule a one-time maintenance window: the listed monitors keep running but their alerts are suppressed between starts_at and ends_at. Use before deploys or planned downtime.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Window title, e.g. 'Database migration' | |
| ends_at | Yes | ISO 8601 datetime with offset - must be after starts_at | |
| timezone | No | IANA timezone for display (default UTC) | |
| starts_at | Yes | ISO 8601 datetime with offset, e.g. 2026-07-12T02:00:00Z | |
| project_id | Yes | Project ID (from list_projects) | |
| description | No | Optional details shown alongside the window | |
| monitor_ids | Yes | Monitors whose alerts to suppress (from list_monitors) |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The resource object |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a write (readOnlyHint=false) but not destructive or idempotent. The description adds behavioral context: alerts are suppressed during the window, monitors keep running. However, it does not disclose what happens after the window ends (alerts likely resume) or whether windows can be modified/deleted, which would be helpful 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?
Two sentences, no wasted words. The description is front-loaded with the core purpose and scoped with a usage example. Every sentence earns its place.
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 presence of an output schema and the tool's complexity (7 parameters, 5 required), the description adequately covers purpose, effect, and usage scenario. A minor improvement would be to explicitly state that alerts resume after the window, but it's not a significant gap.
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?
With 100% schema coverage, baseline is 3. The description adds meaning by explaining that monitor_ids are for suppressing alerts while monitors run, and ties starts_at/ends_at to the suppression period. This extra context elevates the score above baseline.
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 ('Schedule a one-time maintenance window') and explains the effect (monitors keep running but alerts suppressed). It distinguishes from sibling tools like pause_monitor by specifying that monitors remain active, and provides concrete use cases ('before deploys or planned downtime').
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 explicitly recommends usage before deploys or planned downtime, giving clear context. However, it does not discuss when not to use this tool or contrast with alternatives like pause_monitor, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_monitorCreate monitorAInspect
Create a new uptime monitor. Checks start immediately. Types: http, tcp (host:port URL), smtp, ping, ssl, dns. Set inverted=true for exposure monitoring (alert when a target that should stay down becomes reachable).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL for http, host for ping/smtp, host:port for tcp | |
| name | Yes | Display name | |
| type | Yes | Check type | |
| group | No | Optional group name | |
| regions | No | Probe regions (defaults to all) | |
| inverted | No | Exposure monitoring: up while unreachable, alert when reachable | |
| project_id | Yes | Project ID (from list_projects) | |
| timeout_seconds | No | Request timeout in seconds (default 30) | |
| interval_seconds | No | Check interval (default 300) | |
| expected_status_codes | No | HTTP status codes considered up (default: any 2xx) |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The resource object |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that 'Checks start immediately' and explains the 'inverted' parameter behavior. Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description adds useful behavioral context without contradiction. No mention of rate limits or authentication, but acceptable given annotations.
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?
Three sentences with no filler. The first sentence states the core purpose, the second addresses immediate behavior, and the remaining sentences cover types and the key inverted parameter. Every sentence earns its place.
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 creation tool with 10 parameters and an output schema, the description covers essential aspects (types, inverted, immediate start). Schema handles the rest. Could mention that required fields must come from list_projects, but overall adequate.
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 baseline is 3. The description adds value by explaining how 'url' varies by type (e.g., 'host:port for tcp') and what 'inverted=true' does, providing meaning beyond the schema's property descriptions.
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 verb ('Create') and resource ('new uptime monitor'), lists supported types, and directly distinguishes from sibling tools like get_monitor, update_monitor, and list_monitors by explicitly describing creation behavior.
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 when to use (creating a monitor) and clarifies use of the 'inverted' parameter for exposure monitoring. However, it does not explicitly state when not to use this tool or mention alternatives like update_monitor for modifying existing monitors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_incidentGet incidentARead-onlyIdempotentInspect
Get a single incident by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Incident ID |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The resource object |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no additional behavioral context beyond restating the action, such as error handling or rate limits.
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 immediately states the action and scope. No redundant or unnecessary words.
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, output schema present, annotations covering safety), the description is sufficient. However, it could mention that the output object is returned or handle unknown IDs.
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 for the single parameter 'id' is 100% with its description 'Incident ID'. The tool description does not add any further semantics about the parameter 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?
The description uses the specific verb 'Get' and resource 'incident', and clarifies it returns a single incident by ID. This clearly distinguishes it from sibling tools like list_incidents that return 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 for fetching a single incident by ID, but does not explicitly state when to use this tool versus list_incidents or when not to use it. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_monitorGet monitorARead-onlyIdempotentInspect
Get a single monitor by ID, including status, uptime, regions, and settings.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Monitor ID |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The resource object |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds the specific fields returned (status, uptime, regions, settings), providing behavioral context beyond safety traits. No 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?
Single sentence, front-loaded with the core action and resource, no superfluous words.
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 get-by-ID tool with one parameter and output schema, the description fully covers what data is returned. Annotations fill safety profile. No gaps.
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% with clear 'Monitor ID' description. The tool description does not add extra meaning beyond the schema, but this is acceptable since the schema is already sufficient.
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 'Get a single monitor by ID' and lists the included data (status, uptime, regions, settings). This distinguishes it from sibling tools like list_monitors (which returns a list) and get_incident (a different resource).
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 you need details of one specific monitor, contrasting with list_monitors for all monitors. However, it does not explicitly state when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_domainsList domainsARead-onlyIdempotentInspect
List tracked domains with expiry dates, registrar, and days remaining.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (default 25) | |
| cursor | No | Pagination cursor from a previous call | |
| project_id | Yes | Project ID (from list_projects) |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Result rows |
| pagination | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the tool returns specific fields (expiry dates, registrar, days remaining), which is useful but does not disclose potential side effects, auth requirements, or rate limits. No contradiction with annotations.
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?
A single, well-structured sentence that front-loads the action and output. Every word earns its place with no redundancy.
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 3 parameters, an output schema available, and clear annotations, the description is fairly complete. It mentions key output fields, and the schema handles parameter and return value details. Slight lack of pagination hint, but overall adequate for a 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 100%, with limit, cursor, and project_id well-described in the schema. The description does not add new meaning to parameters beyond what the input 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 'List tracked domains with expiry dates, registrar, and days remaining,' providing a specific verb and resource along with output fields. It distinguishes from sibling tools like list_projects or list_monitors by specifying the domain context.
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 explicit when-to-use or when-not-to-use instructions are given. Usage is implied by the domain focus, but no exclusions or comparisons to alternatives are provided. The sibling tools are different enough that context is clear, yet guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_heartbeatsList heartbeatsARead-onlyIdempotentInspect
List heartbeat (cron/background job) monitors in a project, with last-ping status.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (default 25) | |
| cursor | No | Pagination cursor from a previous call | |
| project_id | Yes | Project ID (from list_projects) |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Result rows |
| pagination | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotency; description adds that results include 'last-ping status', which is useful but beyond annotations only provides minimal extra context.
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 that efficiently conveys purpose and output content with no wasted words.
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 good annotations, full schema coverage, and an output schema, the description adequately explains what the tool returns (heartbeat monitors with last-ping status) without needing more detail.
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% with descriptions for all 3 parameters; tool description adds no additional parameter information, so baseline score 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?
Description clearly states it lists heartbeat monitors with last-ping status, distinguishing it from sibling tools like list_monitors which lists all monitor types.
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?
Describes that it lists heartbeat (cron/background job) monitors, implying use when needing those specific monitors, but doesn't explicitly exclude use of list_monitors or provide alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_incidentsList incidentsARead-onlyIdempotentInspect
List incidents (outages) in a project - open and resolved, with timestamps and duration.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (default 25) | |
| cursor | No | Pagination cursor from a previous call | |
| project_id | Yes | Project ID (from list_projects) |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Result rows |
| pagination | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, so safety profile is covered. Description adds that it includes open and resolved incidents with timestamps and duration, which is helpful additional context but does not disclose any unexpected behaviors.
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 front-loads the verb and resource, contains no unnecessary words, and efficiently conveys 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 that an output schema exists (not shown), the description does not need to detail return structure. It mentions key output fields (timestamps, duration). The tool is simple and context from siblings and annotations completes it, though a note about pagination could enhance 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?
Schema description coverage is 100%, so all parameters are documented in the schema. The description does not add further meaning beyond what the schema provides, which is acceptable.
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 incidents (outages) in a project' with specific verb 'list' and resource 'incidents', and clarifies scope and included data ('open and resolved, with timestamps and duration'). It distinguishes from siblings like get_incident and list_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 explicitly state when to use this tool vs alternatives like get_incident for individual incidents. Usage is implied but no exclusions or alternative guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_monitorsList monitorsARead-onlyIdempotentInspect
List uptime monitors in a project, with current status, response time, and 24h uptime.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (default 25) | |
| cursor | No | Pagination cursor from a previous call | |
| project_id | Yes | Project ID (from list_projects) |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Result rows |
| pagination | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds value by specifying return data (status, response time, uptime), which is beyond annotations. No contradictions, but does not discuss pagination behavior or rate limits.
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, front-loaded sentence with no extraneous words. Every part earns its place: verb, scope, resource, and key attributes.
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?
Output schema exists, so return format is covered externally. Description adequately explains what data is returned. Could mention pagination (cursor/limit) but that is already in schema. Overall good completeness for a read-only 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 has 100% description coverage for all three parameters. Description does not add additional parameter-level meaning beyond referencing the resource and returned fields. 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?
Description clearly states verb 'List', resource 'uptime monitors', scope 'in a project', and lists specific returned fields (current status, response time, 24h uptime). It distinguishes from sibling 'get_monitor' which retrieves a single monitor.
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 explicit guidance on when to use this tool versus alternatives like other list tools or monitor-specific tools. Description lacks when/when-not scenarios or mentions of prerequisites beyond 'project_id'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_projectsList projectsARead-onlyIdempotentInspect
List all projects in the workspace. Call this first - most other tools need a project_id.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (default 25) | |
| cursor | No | Pagination cursor from a previous call |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Result rows |
| pagination | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no additional behavioral context beyond the stated purpose, but does not contradict annotations.
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 with no wasted words. The purpose and usage guidance are front-loaded in the first sentence.
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 simple nature of the tool, the description covers enough: purpose, usage order, and implication of output containing project_id. Could mention pagination or output structure, but not 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 description coverage is 100%, so the description does not need to add parameter details. The description provides no extra 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 all projects in the workspace' using a specific verb and resource. It distinguishes from sibling tools as no other sibling tool lists projects.
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 states 'Call this first - most other tools need a project_id', providing clear when-to-use guidance and indicating it is a prerequisite for other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_status_pagesList status pagesBRead-onlyIdempotentInspect
List status pages with visibility, slug, and public URL.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (default 25) | |
| cursor | No | Pagination cursor from a previous call | |
| project_id | Yes | Project ID (from list_projects) |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Result rows |
| pagination | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that it lists with specific fields, which is consistent but does not reveal additional behavioral traits like pagination behavior or rate limits.
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, front-loaded with purpose, no wasted words. Efficiently conveys the core function.
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 output schema exists and annotations cover safety, the description is complete enough for a list operation. Could mention pagination, but that is implied by schema parameters.
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 adds no extra meaning beyond what the schema already provides. Parameter descriptions in the schema are sufficient.
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 lists status pages, a distinct resource from sibling list tools. It mentions specific fields (visibility, slug, public URL) providing clarity on output, but does not explicitly differentiate from other list tools.
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 vs alternatives (e.g., when to list monitors vs status pages). No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pause_monitorPause monitorAIdempotentInspect
Pause a monitor - checks stop until it's resumed. Use before planned work on a single target.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Monitor ID |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The resource object |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds 'checks stop until it's resumed,' providing context beyond annotations but not delving into side effects like alerts or permissions. Given annotation coverage, this is adequate.
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. The core action and usage are front-loaded, making it quick to read and understand.
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, good annotations, and an output schema, the description covers purpose, behavior, and usage context completely. No gaps identified.
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 schema already documents the single parameter 'id' as 'Monitor ID'. The description does not add any additional meaning or parameter-specific guidance 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?
The description clearly states the action ('Pause a monitor') and the behavior ('checks stop until it's resumed'), with usage context ('before planned work on a single target'). It distinguishes itself from sibling tools like resume_monitor and create_maintenance_window.
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 explicitly advises using this tool before planned work on a single target. While it doesn't list when not to use it or mention alternatives, the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resume_monitorResume monitorAIdempotentInspect
Resume a paused monitor - checks start again immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Monitor ID |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The resource object |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent and non-destructive behavior; description adds that checks start immediately, but no further behavioral detail.
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, no wasted words, front-loaded with action and resource.
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?
Sufficient for a simple tool with an output schema; implies the monitor must be paused, but missing explicit prerequisite.
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 adds no meaning beyond 'Monitor ID'—baseline score 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 uses 'Resume a paused monitor' with a specific verb and resource, clearly distinguishing it from siblings like pause_monitor.
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, such as when the monitor is not paused or when other monitoring tools are appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_monitorUpdate monitorAIdempotentInspect
Update a monitor's settings (name, url, interval, inverted, …). Cannot delete.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Monitor ID | |
| url | No | New target: URL for http, host for ping/smtp, host:port for tcp | |
| name | No | New display name | |
| type | No | New check type | |
| group | No | New group name | |
| regions | No | New probe region list | |
| inverted | No | Enable/disable exposure monitoring (alert when reachable) | |
| timeout_seconds | No | New request timeout in seconds | |
| interval_seconds | No | New check interval in seconds | |
| expected_status_codes | No | HTTP status codes considered up |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The resource object |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false. The description adds 'Cannot delete,' reinforcing non-destructiveness, but does not disclose other behavioral traits like authorization or rate limits. With annotations covering the main safety profile, the description adds marginal value.
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: one sentence plus a negation. Every word is purposeful, no fluff. Front-loaded with action and scope.
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 complexity (10 parameters, output schema exists), the description is minimal but covers the core action and a key constraint. However, it lacks context about default behavior (e.g., partial updates) or error scenarios. Adequate but not complete.
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 documents all 10 parameters thoroughly. The description only lists a subset with '...' and does not add meaning beyond the schema. 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 purpose: 'Update a monitor's settings' with specific fields listed, and distinguishes from deletion with 'Cannot delete.' Differentiates from sibling tools like create_monitor (creation) and pause_monitor (state change).
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 usage guidance: it says 'Cannot delete,' which indicates when not to use this tool (for deletion), but does not explicitly contrast with creating or pausing monitors. No explicit when-to-use vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!