Free uptime monitoring: HTTP/TCP/TLS/DNS checks, cron heartbeats, status pages, incident tools.
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.4/5 across 12 of 12 tools scored. Lowest: 3.9/5.
Each tool targets a distinct resource and action. There is no overlap between monitor lifecycle tools (create, get, update, delete, list), incident tools (list, ack, note), or utility tools (check_url, get_account, get_status_page). The descriptions explicitly differentiate check_url from create_monitor, eliminating confusion.
All tool names follow a consistent verb_noun pattern in lowercase snake_case: ack_incident, add_incident_note, check_url, create_monitor, delete_monitor, get_account, get_monitor, get_status_page, list_channels, list_incidents, list_monitors, update_monitor. No mixed conventions or inconsistent verb forms exist.
12 tools is well within the ideal 3-15 range for a monitoring service. Each tool serves a purposeful function without redundancy, covering monitor management, incident handling, and account/status information.
Monitor lifecycle is complete with CRUD plus list. Incidents have list, acknowledge, and note tools, which covers the core incident workflow. Minor gaps include no channel management (only list_channels) and no way to discover status pages (get_status_page requires a known slug), but these are peripheral and workable for most use cases.
ack_incidentAcknowledge an incidentAInspectMark an ongoing incident as "someone is on it" — pauses still-down reminder alerts for that monitor until recovery. Set un=true to un-acknowledge (re-arms reminders).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Incident id (from list_incidents) | |
| un | No | true = remove an existing acknowledgement |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that acknowledgement pauses still-down reminder alerts until recovery, and that un=true re-arms reminders. This goes beyond a generic 'acknowledge' verb, providing insight into 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 two sentences: the first states the core purpose, the second explains the un parameter's effect. No filler or redundant information; 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 low-complexity tool with 2 parameters and no output schema, this description fully covers the action, effect, and parameter semantics. 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% and both parameters already have descriptions. The description adds extra behavioral context for the un parameter by explaining it re-arms reminders, which is beyond the schema's 'remove an existing acknowledgement'. The id parameter is adequately covered by 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 the tool's action: 'Mark an ongoing incident as someone is on it' and explains the effect on reminder alerts. It distinguishes this tool from siblings like list_incidents or add_incident_note by focusing on the acknowledgement action and its consequence.
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 it: during an ongoing incident when someone is handling it, to pause still-down reminders. It also explains the un-acknowledge option. However, it doesn't explicitly name alternative tools or state when not to use it, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
add_incident_noteAdd a postmortem note to an incidentAInspectAttach/replace a note (max 500 chars) on an incident. Notes publish with the incident on public status pages, their JSON and the Atom feed. Empty string clears.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Incident id (from list_incidents) | |
| note | Yes | The note text ("" clears) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: the 500-character limit, the public/publishing nature, and the clearing effect of an empty string. It also notes that notes appear in JSON and Atom feeds, giving the agent a complete picture of the tool's 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?
Two sentences, front-loaded with the core action and constraint. Every clause adds value: the char limit, the publication context, and the clearing behavior are all essential. No fluff or repetition.
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 two-parameter tool with no output schema, the description covers all critical aspects: operation, constraints, side effects, and an edge case (clearing). It is complete for the tool's complexity.
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 schema already documents both parameters well, giving a baseline of 3. The description adds the 500-character limit, which is not present in the schema, and reiterates the clearing behavior, adding practical meaning beyond the structured fields.
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 specific verbs ('Attach/replace') and clearly identifies the resource ('note on an incident'), making the tool's function unambiguous. It also distinguishes itself from siblings by focusing solely on notes, which no other tool handles.
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: you attach notes to incidents, and they are publicly published. However, it does not explicitly mention when to use this tool versus alternatives, though no direct alternative exists among siblings. This is clear enough for an 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.
check_urlInstant URL check (no account needed)ACheck any public URL RIGHT NOW: is it up, HTTP status, response time in ms. Works without an API key (rate limit 10/hour per IP). For continuous monitoring with alerts, use create_monitor.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public http(s) URL to check, e.g. https://example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint, but the description adds valuable behavioral details: no API key required, a rate limit of 10/hour per IP, and that it returns HTTP status and response time. These go beyond the structured annotations and are critical for the agent to understand usage constraints.
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, front-loaded with the core action and output, and includes essential usage constraints and an alternative tool. Every sentence adds value 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?
For a simple tool with one parameter and no output schema, the description is fully adequate: it states the purpose, the rate limit, the alternative for continuous monitoring, and expected outputs (status, response time). No critical information 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?
The input schema covers the only parameter 'url' with 100% description coverage. The tool description does not add extra semantics beyond the schema, merely restating that it checks 'any public URL'. Since the schema already documents it, 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's function: 'Check any public URL RIGHT NOW: is it up, HTTP status, response time in ms.' It specifies the verb (check), resource (public URL), and outputs (status, response time). It also distinguishes from siblings by emphasizing one-off checks versus continuous monitoring via 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?
The description explicitly says when to use this tool ('Check any public URL RIGHT NOW') and when not to, directing to an alternative: 'For continuous monitoring with alerts, use create_monitor.' It also mentions the rate limit (10/hour per IP) and lack of API key, giving clear operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_monitorCreate a monitorAInspectCreate a monitor. kind=http (needs url), tcp (target "host:port"), tls (target host[:port] — cert-expiry watch), domain (target — registration-expiry via RDAP), dns (target + rtype A/AAAA/MX/... , optional expect_value), heartbeat (dead-man’s switch for cron jobs/agent loops: needs name; response includes ping_url to curl from the job, and a ping_email address). Common options: name, interval (seconds, min 60), tags. http options: expect ("2xx,301"), keyword, keyword_absent:"absent", slow_ms (number or "auto"), method, headers, body, json_path/json_expect, header_name/header_expect. heartbeat options: grace (seconds), cron ("0 3 * * *") + tz, max_duration_s. Any other documented field (see /llms.txt) also works — extra properties are passed through.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | For kind=http: the URL to check | |
| kind | No | Monitor kind (default http) | |
| name | No | Display name (required for heartbeat, defaults to the target host otherwise) | |
| target | No | For tcp/tls/domain/dns: host[:port] or domain name | |
| interval | No | Check interval in seconds, min 60 (heartbeat: expected ping interval) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that heartbeat responses include ping_url and ping_email, and that 'extra properties are passed through' to the API, which is valuable transparency. It does not mention error cases or side effects, but for a create operation the behavior is well-scoped.
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 dense but well-organized: main purpose, then kind-specific details in a logical order, then common and per-kind options. Every sentence adds useful information; no filler. The use of abbreviations and examples (e.g., 'host:port', '2xx,301') makes it compact yet 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 complexity of six kinds with many options and no output schema, the description is remarkably complete. It covers common options, per-kind requirements, and even notes the response includes ping_url for heartbeat. The pointer to /llms.txt for additional fields fills any remaining 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?
Despite 100% schema coverage, the description adds significant depth by mapping schema parameters to specific kinds (e.g., url for http, target for tcp/tls/domain/dns), explaining common options like interval and tags, and detailing kind-specific options (slow_ms, expect, keyword, etc.) not listed in the schema. This goes far beyond the schema's basic 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 starts with a clear verb+resource ('Create a monitor') and enumerates all six kinds with specific purposes (http, tcp, tls, domain, dns, heartbeat). It distinguishes itself from sibling tools like update_monitor and delete_monitor by focusing on creation and explaining each kind's unique 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?
The description provides implicit usage guidance by explaining what each kind is for (e.g., heartbeat is for cron jobs/agent loops) and which options apply to which kind. It does not explicitly state when not to use it, but as the only create tool among siblings, the context is clear. It also directs users to /llms.txt for additional fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_monitorDelete a monitorAPermanently delete a monitor and all its check history, events and rollups. Cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Monitor id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the destructiveHint annotation by specifying exactly what is destroyed (check history, events, rollups) and stating that the action cannot be undone. This provides valuable behavioral context that helps the agent understand the full impact of the operation.
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 primary action ('Permanently delete a monitor') and then provides essential consequences. Every word adds value, 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?
For a simple, one-parameter destructive tool, the description fully covers the action, its consequences, and irreversibility. The annotation confirms the destructive nature, and the schema covers the parameter. No additional context is needed for an agent to use it 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 already fully describes the only parameter (id) with 100% coverage. The description adds no additional meaning about the id parameter, so the 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 deletes a monitor permanently, with a specific verb and resource. It also details what is removed (check history, events, rollups) and emphasizes irreversibility, distinguishing it from sibling 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?
Usage context is implied: this is the tool to permanently remove a monitor. However, there is no explicit guidance on when to choose this over alternatives like update_monitor, or any warning to consider backups (beyond noting irreversibility). The purpose is clear enough that a user can infer when to use it, but the guidance is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_accountAccount overviewAWho am I: account email, monitor count/limit, plan limits. Good first call to verify the API key works.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds value by listing the exact data returned (email, monitor counts/limits, plan limits) and the intended use case for API key verification. This goes beyond the bare read-only flag, though it doesn't cover error cases 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?
Two short sentences. The first sentence immediately answers 'who am I' with concrete outputs, and the second gives a practical use case. No filler 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 stateless read-only call with no parameters and no output schema, the description fully covers what an agent needs: what it does, what it returns, and when to call it. The sibling tools list confirms this is the only account-level operation, so no missing context.
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 tool has zero parameters, so there is no parameter schema to explain. The description compensates by explaining what the tool returns, which is more relevant for expected output than parameters. Baseline for 0 params is 4, and the description fully satisfies that.
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's purpose: it returns account email, monitor count/limit, and plan limits. This is a specific verb-resource pair ('get account') that is distinctly separate from all sibling tools, which focus on monitors, incidents, channels, 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?
Explicitly suggests using this as a 'good first call to verify the API key works,' providing clear context for when to use it. It doesn't mention alternatives or exclusions, but the uniqueness of the account-level operation makes alternatives unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_monitorGet one monitorAFull detail for one monitor: status, config, 24h latency percentiles and trend (http/tcp), SLA budget if a target is set. Heartbeat monitors include their ping_url and ping_email.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Monitor id (from list_monitors) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint annotation already indicating a safe read, the description adds valuable context by enumerating exactly what 'full detail' includes (status, config, latency percentiles, SLA budget, heartbeat URLs). This goes beyond the annotation without contradicting it.
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 front-loads the core purpose and efficiently lists included details. No filler 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?
Despite lacking an output schema, the description thoroughly specifies the returned data, including conditional items like SLA budget and heartbeat URLs. This is sufficient for a simple read tool with one parameter.
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% for the single 'id' parameter, and the schema already explains its source. The description does not add further parameter semantics, making the baseline score of 3 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's function: 'Full detail for one monitor' with a specific verb and resource. It distinguishes itself from sibling tools like list_monitors by focusing on a single monitor's complete details.
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 retrieving detailed information about a specific monitor, especially since the parameter references list_monitors for obtaining the id. However, it does not explicitly discuss when not to use it or contrast with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_status_pageRead a public status pageAMachine-readable state of any public Watchpup status page by slug: per-monitor status, uptime, incidents last 30d. No API key needed.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Status page slug (the part after /s/) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, but the description adds meaningful context beyond those: it specifies the exact data returned (per-monitor status, uptime, incidents last 30d) and the auth requirement (no API key). This is additional transparency 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 a single, efficiently packed sentence. It front-loads the core function ('Machine-readable state of any public Watchpup status page') and then lists the returned categories and auth note without any 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?
For a simple one-parameter read tool, the description is largely complete: it names the endpoint by slug, the data categories, and the public auth requirement. It lacks details on error behavior or exact formatting, but the absence of an output schema is compensated by the listed return contents.
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 schema already provides 100% coverage for the 'slug' parameter, describing it as 'Status page slug (the part after /s/)'. The description repeats this ('by slug') without adding new meaning, so it does not exceed the baseline for high schema coverage.
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 reads machine-readable state of a public status page by slug, listing per-monitor status, uptime, and incidents. It distinguishes itself from sibling tools like get_monitor and list_monitors by targeting a public status page rather than individual monitors or lists.
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 notes 'No API key needed', providing an important usage criterion for public pages. It implies use when you need status page data by slug, but does not explicitly contrast with alternatives like get_account or list_incidents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_channelsList alert channelsAAlert delivery channels on the account (email / webhook / Discord / Slack / ntfy / Telegram), their verification state and delivery health.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation. The description adds behavioral context by specifying the returned content: verification state and delivery health, along with the supported channel types. This goes beyond the annotation without contradicting it.
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, information-dense sentence that leads with the core purpose and packs in the channel types and result attributes without redundancy. It earns a 5.
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?
This is a simple, parameterless, read-only tool. The description fully conveys what the agent will get: all alert channels of specified types, with their verification and health status. No output schema exists, but the description covers the essential return information, making it complete for the tool's complexity.
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 zero parameters, so the baseline is 4. The description doesn't need to explain parameters; it instead clarifies the scope of the list, which is 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 the tool lists alert delivery channels on the account, enumerating the supported channel types (email, webhook, Discord, Slack, ntfy, Telegram) and specifying the returned attributes (verification state, delivery health). This distinguishes it from sibling list tools such as list_monitors or list_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 provides clear context by scoping the tool to account-level alert channels, which implies its use case. However, it does not explicitly mention when to prefer this over other list tools or state any exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_incidentsList incidentsADowntime incidents (ongoing and resolved) across all monitors: start, duration, cause, acknowledgement, notes.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback window in days, 1-90 (default 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true, the description adds value by specifying the scope (ongoing and resolved), the all-monitor coverage, and the returned fields (start, duration, cause, acknowledgement, notes). This goes beyond the annotation without contradiction.
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 resource, scope, and returned fields in a compact manner. 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-optional-parameter tool with no output schema, the description lists the key fields returned and the coverage of all monitors, which is sufficient for an agent to understand the tool's behavior. Schema fills in the default lookback.
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 schema already provides a full description for the only parameter 'days' (lookback window, 1-90, default 30). The description adds no additional semantics for this parameter, so 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 the tool lists downtime incidents (both ongoing and resolved) across all monitors, with specific fields returned. This distinguishes it from sibling tools like ack_incident and add_incident_note, which act on incidents rather than listing them.
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 specifying 'across all monitors' and the incident fields, giving clear context. It does not explicitly mention alternatives or exclusions, but since this is the only incident-listing sibling, no further guidance is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_monitorsList monitorsAList all monitors on the account: current up/down status, kind, target, interval, last check. Optionally filter by tag.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Only monitors carrying ALL these tags (comma-separated), e.g. "prod" or "prod,eu" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this as safe, and the description adds concrete behavioral details about the response fields and optional tag filtering. It does not disclose pagination or rate limits, but for a simple list operation this is acceptable.
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, front-loaded with the core action and resource. Every word contributes meaning; no fluff.
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 tool with one optional parameter and readOnlyHint annotation, the description adequately covers the response contents and filtering behavior. It lacks details on ordering or size limits, but these are not critical for this simple 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 schema fully covers the 'tag' parameter with a clear description, achieving 100% coverage. The description merely restates that filtering by tag is optional, adding no semantic value 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 begins with 'List all monitors on the account,' a specific verb+resource that clearly identifies the tool's function. It enumerates the return fields (up/down status, kind, target, interval, last check), distinguishing 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 states the tool lists all monitors and optionally filters by tag, providing clear context for when to use it. However, it does not explicitly reference alternatives or exclusions, such as 'for a single monitor use get_monitor.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_monitorUpdate / pause / resume a monitorAInspectPATCH any monitor field: name, url, target, interval, expect, keyword, slow_ms, grace, cron, tags, sla_target, renotify, channels (alert routing)... Pause with {"status":"paused"}, resume with {"status":"new"}. Empty string clears optional fields.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Monitor id | |
| status | No | "paused" stops checking; "new" resumes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description must disclose behavioral traits itself. It adds useful context: 'Empty string clears optional fields' and status values 'paused' stops checking, 'new' resumes. However, it does not describe side effects, permission requirements, or the consequence of omitting fields beyond what PATCH implies, leaving some gaps.
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, two sentences, with the core action 'PATCH any monitor field' front-loaded, followed by a list of examples and special behaviors. There is no redundant wording 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?
The description covers many fields and the pause/resume mechanics, but lacks information on prerequisites like the need for an existing monitor, error handling, permission requirements, or expected response format. Given it is a mutation tool with no annotations or output schema, it could be more 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?
The schema only documents id and status, but the description enumerates many additional patchable fields (name, url, target, interval, expect, keyword, slow_ms, grace, cron, tags, sla_target, renotify, channels) and clarifies behavior for status and empty strings. This significantly compensates for the schema's limited parameter coverage.
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 'PATCH any monitor field' and lists a range of specific fields (name, url, target, interval, etc.), which precisely identifies the tool's function as updating existing monitors. The title 'Update / pause / resume a monitor' further disambiguates it from sibling tools like create_monitor, delete_monitor, and get_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 on existing monitors through 'PATCH any monitor field' and provides specific instructions for pausing and resuming via the status parameter, but it does not explicitly contrast this tool with alternatives like create_monitor or delete_monitor, nor does it mention prerequisites such as requiring an existing monitor ID.
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!
