Uptime and website monitoring for AI agents. Query monitor status, incidents, heartbeats, domain expiry, and status pages in your Vantaj Uptime workspace.
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.
Average 4.1/5 across 13 of 13 tools scored.
Every tool targets a distinct resource-action pair. Monitor-related tools use distinct verbs (create, get, list, update, pause, resume), and the two alert-suppression mechanisms (maintenance window vs pause) are clearly differentiated in descriptions.
All tools follow a consistent lowercase verb_noun pattern (create_, get_, list_, update_, pause_, resume_). No mixing of conventions.
13 tools provide a comprehensive but focused interface for uptime monitoring, well within the ideal range.
The set lacks a delete operation for monitors, an important part of the monitor lifecycle, and maintenance windows can be created but not listed or updated. Core monitoring operations are covered, but these gaps could require workarounds.
create_maintenance_windowCreate maintenance windowAInspectSchedule 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) |
| Name | Required | Description |
|---|---|---|
| data | Yes | The resource object |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (readOnlyHint false, idempotentHint false, etc.) only indicate side effects, but the description adds key behavioral context: alerts are suppressed while monitors keep running, and the window is one-time. This goes beyond the structured flags, though it does not mention issues like overlapping windows or permissions.
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 the purpose, followed by a usage hint. Every clause adds value and there is 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?
For a create-style tool with 7 parameters, the description covers the core behavior, the temporal scope, and a common use case. The presence of a detailed input schema and output schema means the description does not need to enumerate return values or every constraint. It is complete for an agent to select and invoke correctly.
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 baseline is 3. The description references starts_at and ends_at, but the schema already explains each parameter in detail, including 'from list_projects' and 'Monitors whose alerts to suppress.' The description does not add significant 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 states a specific action and resource: 'Schedule a one-time maintenance window.' It further clarifies the effect by explaining that 'the listed monitors keep running but their alerts are suppressed between starts_at and ends_at,' which clearly distinguishes it from sibling tools like pause_monitor and create_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?
It provides clear usage context with 'Use before deploys or planned downtime,' which tells the agent when to invoke this tool. It does not explicitly name alternative tools or exclusion scenarios, but the context is strong enough to differentiate from pausing or creating monitors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_monitorCreate monitorAInspectCreate 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) |
| Name | Required | Description |
|---|---|---|
| data | Yes | The resource object |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (all false), so the description carries the burden of explaining behavior. It adds useful context: checks start immediately, tcp uses host:port URL, and inverted enables exposure monitoring. These details go beyond what annotations provide.
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 three short sentences, front-loaded with the main purpose, and contains no filler. Every sentence contributes useful 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 schema and output schema cover parameter details and return values, the description is complete enough. It highlights key behavioral aspects (immediate start, exposure monitoring) but omits guidance on other parameters like regions or expected_status_codes, though these are documented in the schema.
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% parameter coverage, so the schema already documents all parameters. The description's mention of types and inverted adds minimal new meaning, mostly rephrasing the schema 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 tool creates a new uptime monitor, which is a specific verb and resource. It also lists the supported monitor types, distinguishing it from sibling tools like update_monitor or 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?
The description implies usage by naming the action and notes that checks start immediately, but it does not explicitly compare to alternatives or describe when not to use this tool. It provides clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_incidentGet incidentAGet a single incident by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Incident ID |
| Name | Required | Description |
|---|---|---|
| data | Yes | The resource object |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds only the scope ('single by ID'), not additional behavioral traits such as error behavior or prerequisites, so it provides minimal value beyond 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?
One sentence, thirteen words, directly front-loaded with the action.
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, read-only, idempotent, output schema present), the description is adequate to understand its function without further elaboration.
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 'Incident ID' for the id parameter. The description's 'by ID' reinforces this but adds no additional semantic detail.
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 verb 'Get' with resource 'incident' and specifies 'single ... by ID', clearly distinguishing it from sibling list_incidents and other 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?
The description communicates clear context: use this tool to retrieve a specific incident when you have its ID. It doesn't explicitly name alternatives like list_incidents, but the 'single' qualifier implies the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_monitorGet monitorAGet a single monitor by ID, including status, uptime, regions, and settings.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Monitor ID |
| Name | Required | Description |
|---|---|---|
| data | Yes | The resource object |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds what the response includes (status, uptime, regions, settings), which is useful context but doesn't go beyond typical get-by-ID 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?
One concise sentence, front-loaded with the verb and resource. 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?
A simple get-by-ID tool with output schema and clear annotations; the description covers the purpose and invocation need. No additional context is required.
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 covers the only parameter ('Monitor ID') 100%, so the description adds no extra meaning. 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?
Description clearly states the verb 'Get', resource 'monitor', and scope 'by ID' with a list of return contents. This distinguishes it from siblings like list_monitors and get_incident.
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 specific monitor by ID, contrasting with list_monitors for multiple monitors. It doesn't explicitly name alternatives or exclusions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_domainsList domainsAList 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) |
| Name | Required | Description |
|---|---|---|
| data | Yes | Result rows |
| pagination | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds output-content context ('with expiry dates, registrar, and days remaining') but doesn't disclose additional behavioral traits like pagination behavior or authentication needs, which are partly evident from schema parameters and 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?
The description is a single, front-loaded sentence that conveys the core purpose efficiently with no wasted words. It includes meaningful qualifiers ('tracked') and output specifics without 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?
For a simple read-only list tool with full schema parameter coverage, annotations, and an output schema, the description is sufficiently complete. It doesn't need to explain return values (output schema exists) or safety (annotations cover it). The only minor gap is explicit usage guidance, but the tool's simplicity and schema compensate.
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%, with each parameter (limit, cursor, project_id) already described. The tool description adds no parameter-level semantics beyond what the schema provides, so the baseline score of 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 the verb 'List' with the resource 'tracked domains' and specifies the key output fields ('expiry dates, registrar, and days remaining'). This distinguishes it from sibling list tools like list_monitors or list_projects by clarifying it focuses on domain data.
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 (you call this when you need domain expiry info), but it does not explicitly state when to use this tool versus alternatives or provide exclusions. The schema parameter 'project_id' references list_projects, which hints at a prerequisite, but the description itself offers no such guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_heartbeatsList heartbeatsAList 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) |
| Name | Required | Description |
|---|---|---|
| data | Yes | Result rows |
| pagination | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds value by clarifying what heartbeats are (cron/background jobs) and what data is included (last-ping status), which goes beyond the structured fields.
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 with no wasted words. It front-loads the primary action and includes a useful detail (last-ping status) without 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?
The tool is simple, with a clear purpose, sufficient annotations, a complete input schema, and an output schema. The description fully covers the conceptual context needed to select and invoke the tool correctly.
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 three parameters, including descriptions for limit, cursor, and project_id. The description adds little beyond the schema, which is acceptable given the schema's thoroughness.
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 heartbeat (cron/background job) monitors within a project and includes last-ping status. This specific verb+resource+scope distinguishes it from sibling tools like list_monitors, which covers all 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 provides clear context by specifying the scope to heartbeat monitors in a project, implying when to use it (when monitoring cron/background jobs). However, it does not explicitly state when not to use it or name alternatives, though the distinction from sibling tools is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_incidentsList incidentsAList 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) |
| Name | Required | Description |
|---|---|---|
| data | Yes | Result rows |
| pagination | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive. The description adds value by disclosing that both open and resolved incidents are returned and that timestamps and duration are included, which is useful behavioral detail beyond the 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, front-loaded sentence with no redundant wording. Every phrase earns its place by clarifying scope and output content.
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 list operation with good annotations, an output schema, and full schema coverage, the description is complete. It covers purpose, scope, and included data without unnecessary elaboration.
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 fully documents all parameters. The description only adds minimal contextual meaning ('in a project') beyond the schema, not detailed parameter-level semantics.
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 and resource ('List incidents') and clearly defines scope ('in a project') and content ('open and resolved, with timestamps and duration'). This distinguishes it from sibling tools like get_incident (singular) 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 gives clear context: use the tool to list incidents within a project. It does not explicitly name alternatives or exclusions, but the scope is well-defined and no conflicting guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_monitorsList monitorsAList 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) |
| Name | Required | Description |
|---|---|---|
| data | Yes | Result rows |
| pagination | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that results include current status, response time, and 24h uptime, which is useful but does not go beyond what is expected for a simple list tool. No mention of pagination, but the schema provides that.
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 one short sentence, front-loaded with the main verb 'List', and contains no unnecessary words or repeated information. It is concise and immediately informative.
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, the description does not need to explain return values. The combination of clear purpose, strong annotations for safety, and schema-documented pagination makes this description complete for a simple 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?
The input schema covers all three parameters (limit, cursor, project_id) with descriptions, so schema coverage is 100%. The tool description does not add any extra meaning to these parameters, so the 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 clearly states the action ('List'), the resource ('uptime monitors'), and the scope ('in a project'), while also noting the included fields (status, response time, 24h uptime). This effectively distinguishes it from sibling tools like get_monitor, which targets 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?
The description provides clear context for when to use it (to list monitors within a project), but it does not explicitly mention alternatives or when not to use it. The presence of get_monitor makes the intended use fairly clear, but explicit exclusions would push it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_projectsList projectsAList 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 |
| Name | Required | Description |
|---|---|---|
| data | Yes | Result rows |
| pagination | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clearly positive. The description adds valuable behavioral context about the tool's role as a prerequisite for other tools, which is not captured by the annotations or schema. No contradictions found.
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 long and front-loaded with the primary purpose. Every word earns its place: the first sentence states exactly what the tool does, and the second provides critical usage guidance. No fluff or 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?
For a simple, read-only list tool with two optional parameters and an output schema, the description is complete. It explains the tool's role as a first-step dependency, and the annotations and schema cover safety and parameter details. No meaningful 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 description coverage is 100%, with clear descriptions for 'limit' and 'cursor'. The tool description does not add any additional parameter semantics beyond saying 'all projects', which is consistent with the schema. With full schema coverage, a 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 clearly states the tool lists all projects in the workspace, with a specific verb ('List') and resource ('projects'). It distinguishes itself from sibling tools by being the sole project-listing tool and adds the important context that it should be called first because most tools need a project_id.
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 explicit guidance on when to use the tool ('Call this first') and why (most other tools need a project_id). It does not mention when not to use it or name alternatives, but the resource is distinct enough that alternatives are not relevant, so the clear context earns a 4.
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 pagesAList 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) |
| Name | Required | Description |
|---|---|---|
| data | Yes | Result rows |
| pagination | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, which cover the safety profile. The description adds no new behavioral traits beyond restating the list action; it doesn't mention pagination behavior, default limit, or any side effects. With annotations carrying the main risk disclosure, the description adds minimal 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 a single, front-loaded sentence with no wasted words. It clearly conveys the action and resource without verbosity, making it easy to parse quickly.
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 list operation, strong annotations, and existing output schema, the description is sufficiently complete. It doesn't need to explain return values because an output schema exists, and pagination is documented in the input schema. The description plus annotations leave no critical gaps for agent use.
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% parameter description coverage, including explanations for limit, cursor, and project_id. The description provides no additional parameter semantics, so it doesn't exceed what the schema already documents. 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 states a specific action ('List status pages') with a clear resource and even hints at key output attributes ('visibility, slug, and public URL'). This distinguishes it from sibling listing tools like list_projects or list_monitors by naming the unique 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?
No explicit when-to-use guidance is given, but the tool name and description make it clear that it is for listing status pages, distinct from listing other resources. There are no stated exclusions or alternatives, so usage is implied rather than explicitly contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pause_monitorPause monitorAPause a monitor - checks stop until it's resumed. Use before planned work on a single target.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Monitor ID |
| Name | Required | Description |
|---|---|---|
| data | Yes | The resource object |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotent, non-destructive, and non-read-only behavior. The description adds the key behavioral effect that checks stop until resumed, which is useful context beyond the annotations. No contradiction found.
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 short sentences, front-loaded with the purpose and immediately stating usage context. No redundant information or filler 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 one-parameter tool with full schema coverage, output schema present, and appropriate annotations, the description provides purpose, effect, and usage guidance. It is complete enough for an agent to select and invoke the tool correctly.
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 a clear description for the one parameter ('Monitor ID'). The tool description does not add extra parameter semantics, but the schema already fully documents the parameter, so the baseline score of 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 'Pause a monitor' with a specific verb and resource, and explains the effect ('checks stop until it's resumed'). It also distinguishes from the sibling tool 'resume_monitor' by describing the opposite action.
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 explicit usage context: 'Use before planned work on a single target.' This implies a specific scenario and hints at limitations (single target), but does not explicitly mention alternatives like 'create_maintenance_window' for multiple targets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resume_monitorResume monitorAResume a paused monitor - checks start again immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Monitor ID |
| Name | Required | Description |
|---|---|---|
| data | Yes | The resource object |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the operation is idempotent and non-destructive. The description adds the useful behavioral detail that checks resume immediately. It does not contradict annotations, though it could mention behavior if the monitor is already running.
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 filler, front-loading the action and outcome. Every word 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 simple one-parameter tool with annotations and an output schema, the description is largely sufficient. It could explicitly state the prerequisite that the monitor must be paused, but this is already implied by the phrase 'paused monitor'.
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 fully documents the single 'id' parameter as 'Monitor ID', so the description adds no additional parameter semantics. With high schema coverage, the 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 clearly states the tool resumes a paused monitor, using a specific verb and target resource. It naturally distinguishes itself from sibling tools like pause_monitor. The phrase 'checks start again immediately' also clarifies the expected effect.
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 clear context by stating that this tool operates on a paused monitor, implying the correct scenario for use. It does not explicitly mention alternatives or exclusions, but the intended use case is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_monitorUpdate monitorAUpdate 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 |
| Name | Required | Description |
|---|---|---|
| data | Yes | The resource object |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds a minor clarification ('Cannot delete') and lists some settings, but does not disclose partial-update semantics or other behavioral nuances. This is sufficient but not rich.
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 that front-loads the core action and ends with a relevant limitation. 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?
While the schema and annotations cover most details, the description omits whether the tool performs a partial update (only provided fields) or a full replacement. This is a significant gap given 10 optional parameters. The output schema exists, so return values don't need explanation, but this key behavioral detail is missing.
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%, with each parameter already described in detail. The description only lists a few parameter names without adding semantic meaning beyond the schema, so it does not elevate the 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 uses the specific verb 'Update' and identifies the resource as 'a monitor's settings', listing example fields like name, url, interval, inverted. The note 'Cannot delete' clearly distinguishes this tool from deletion operations and from sibling tools like create_monitor, pause_monitor, and resume_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?
The description clearly implies this tool is for modifying existing monitor settings, but it does not explicitly state when to use it over alternatives (e.g., create_monitor for new monitors) or provide prerequisites. The 'Cannot delete' is an exclusion but not a full alternative recommendation.
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.
No comments yet. Be the first to start the discussion!
