Check updown.io uptime checks, downtimes, response metrics and status pages, and create checks.
Scored across 14 tools
Most tools target a clearly distinct resource+action (checks, status pages, recipients, nodes). Minor overlap exists between updown_find_problems and updown_list_checks (both derived from GET /api/checks) and between updown_list_nodes and updown_list_node_ips, but the specialized framing of each keeps them separable.
Every tool uses the same updown_ prefix followed by a consistent verb_noun pattern (list_checks, create_check, get_check_metrics, update_status_page). No camelCase/snake_case mixing or drifting verb styles.
14 tools sit squarely in the well-scoped range for a monitoring platform covering checks, status pages, recipients, and node info. Each tool maps to a distinct API operation and none feels redundant.
Create/read/update coverage is solid for checks and status pages, but delete operations are entirely absent (no delete_check, delete_status_page, or remove_recipient), and recipients lack update/delete despite supporting add. These gaps limit full lifecycle management.
Add an alert recipient: an email address, phone number (sms), webhook URL, Slack-compatible incoming-webhook URL, or Microsoft Teams webhook URL. Returns the new (or already-existing) recipient with its id. By default it is selected on ALL existing checks; pass selected=false to add it unattached. Slack/Telegram/Zapier/Statuspage integrations must be set up in the web UI. Requires the read/write API key. updown: POST /api/recipients.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional friendly label (webhooks only at the moment). | |
| type | Yes | Recipient type. | |
| value | Yes | The email address, phone number or URL. | |
| selected | No | true (default) = selected on all existing checks; false = not selected on any check. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations supply only destructiveHint=true, so the description carries the burden and does so well: it discloses that the call may return an already-existing recipient (idempotent dedupe), that the new recipient is auto-attached to ALL existing checks unless selected=false, that an API key is required, and that some integrations require prior web-UI setup. These are exactly the side effects an agent needs before mutating alert routing.
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?
Information-dense and front-loaded: purpose and return value come first, then side effects, then prerequisites. The middle clause stacking several URL types is slightly run-on, but no sentence is filler.
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 no output schema, the description steps in by describing the return ('the new (or already-existing) recipient with its id'). Combined with the prerequisite and default-selection notes, an agent has enough to call it correctly; only error/failure modes (invalid webhook, duplicates by value) are unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning by mapping each type to the corresponding value format ('phone number (sms)', 'Slack-compatible incoming-webhook URL', 'Microsoft Teams webhook URL'), which the schema's plain enum does not explain. It also restates the selected=true default in behavioral terms.
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?
States a specific verb+resource ('Add an alert recipient') and immediately enumerates the accepted recipient forms, so an agent can tell it apart from updown_list_recipients without opening the schema. The endpoint hint ('updown: POST /api/recipients') reinforces exactly what object is created.
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?
Gives real preconditions: read/write API key required, and Slack/Telegram/Zapier/Statuspage integrations must already exist in the web UI. It also explains the default selection behavior and how to opt out with selected=false. It stops short of naming the sibling tool for listing existing recipients, so it is clear context rather than full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a new monitoring check. The type (http, https, tcp, tcps, icmp) is inferred from the URL scheme; pass type 'pulse' (and no URL) for a cron/heartbeat check. Each check consumes updown credits while enabled. Requires the read/write API key. updown: POST /api/checks.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | The URL to monitor, e.g. https://example.com, tcp://host:port, icmp://host. Omit for pulse checks. | |
| type | No | Check type; inferred from the URL by default — mainly useful for 'pulse'. | |
| alias | No | Human-readable name for the check. | |
| period | No | Interval in seconds. Regular checks: 15, 30, 60, 120, 300, 600, 1800 or 3600 (default 60). Pulse checks: anywhere from 15 s to 1 month. | |
| apdex_t | No | APDEX threshold in seconds: 0.125, 0.25, 0.5, 1.0, 2.0, 4.0 or 8.0 (default 0.5). | |
| enabled | No | Whether the check runs. false pauses it (reversible). | |
| http_body | No | HTTP body sent with the request. | |
| http_verb | No | HTTP verb for the request (default GET/HEAD). | |
| published | No | Whether the check's public status page is visible (default false). | |
| mute_until | No | Mute notifications until a time (ISO8601, e.g. 2026-10-01T08:00:00Z), or 'recovery', or 'forever'. | |
| recipients | No | Alert recipient ids to select, e.g. ['email:12345', 'sms:67890'] (from updown_list_recipients). | |
| string_match | No | Text that must appear in the response. For TCP/TCPS checks, '<closed>' inverts the check (alert if the port is open). | |
| custom_headers | No | HTTP headers updown sends with each request, e.g. { "X-Api-Key": "..." }. | |
| disabled_locations | No | Monitoring locations to disable: lan, mia, tor, rbx, fra, cap, hel, sin, tok, syd. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only carry destructiveHint=true, so the description adds real value: it discloses that each check consumes updown credits while enabled and that a read/write API key is required. It does not say what the call returns (e.g. a new check id) or note any limits on check count, which would have been the remaining useful disclosures.
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?
Four short sentences, each carrying distinct information — creation, type inference, billing impact, auth — with the API key requirement and endpoint reference trailing at the end. Zero filler.
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 14-parameter mutation tool with no required fields and no output schema, the description covers the highest-risk unknowns (auth level, credit cost, the pulse branch). Its main omission is the return value, which matters here precisely because no output schema exists to document it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the 14 parameters are already documented and the baseline is 3. The description nonetheless adds cross-parameter meaning the schema cannot express on its own: type is derived from the URL scheme, and the url/type pair must be used inversely for pulse checks.
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?
States a specific verb and resource ('Add a new monitoring check') and then clarifies the creation semantics in a way no sibling does — type inference from URL scheme, and the pulse/no-URL special case. An agent can distinguish this from updown_update_check or updown_get_check purely from the text.
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?
Gives concrete selection guidance for the tricky branch (pass type 'pulse' and omit url for cron/heartbeat checks) and surfaces the read/write API key prerequisite. It never explicitly names the alternative (updown_update_check) for modifying an existing check, so it stops short of full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a status page showing the given checks, in order. Returns its token and URL. Requires the read/write API key. updown: POST /api/status_pages.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Name of the status page. | |
| checks | Yes | Check tokens to show, in display order, e.g. ['dmbe', 'ngg8']. | |
| access_key | No | Access key for protected pages (defaults to a random 30-byte string). | |
| visibility | No | Page visibility (default public). | |
| description | No | Text displayed below the name (supports newlines and links). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavior beyond the annotations: the auth requirement (read/write API key) and the return payload (token and URL). It does not contradict destructiveHint=true and does not need to restate it, but gives no detail on ordering side effects or failure modes.
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 short sentences, front-loaded with the action, then return value, then prerequisite. The trailing REST mapping is marginal but costs almost nothing.
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 no output schema, stating the returned token and URL is exactly the right compensation, and the auth prerequisite is covered. Only minor gaps remain (e.g., visibility semantics are left entirely to 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?
Schema coverage is 100%, so all five parameters are already documented, including display order and the token pattern. The description's 'in order' clue largely duplicates the checks parameter description, so 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?
Specific verb (Create) plus resource (status page) with a distinguishing scope detail (the given checks, in order). It is clearly separable from updown_update_status_page and updown_list_status_pages without opening a schema.
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?
States a prerequisite ('Requires the read/write API key') but gives no when/when-not guidance or named alternatives. Usage context is only implied by the verb (new page vs. updating an existing one).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-call health overview across every check: which are DOWN (since when, error), which have an invalid SSL certificate, which certificates or domains expire within N days, and which checks are paused or muted. Built from GET /api/checks.
| Name | Required | Description | Default |
|---|---|---|---|
| ssl_days | No | Flag SSL certificates expiring within this many days (default 14). | |
| domain_days | No | Flag domains expiring within this many days (default 30). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true, so the description carries the rest: it discloses that results span four distinct problem classes including paused/muted checks, and that it is derived from GET /api/checks. It omits return shape, ordering, or pagination behavior, but adds real context beyond the annotation.
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 core purpose and the four problem categories are front-loaded in a single dense sentence, with the data source relegated to a trailing note. Slightly long but every clause adds information; little waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does the work of telling the agent what comes back by enumerating the problem categories. It stops short of describing the result structure (grouped lists vs. flat), which is a modest gap for a reporting tool, but overall it is sufficient to call 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%, so the baseline would be 3, but the description frames both parameters conceptually as 'expire within N days' thresholds tied to the SSL/domain expiration checks. That clarifies what each numeric window controls, going slightly beyond the schema's own wording.
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 verb and scope ('One-call health overview across every check') and enumerates exactly what it surfaces (DOWN checks with duration/error, invalid SSL, expiring certs/domains, paused/muted). This clearly separates it from siblings like updown_list_checks and updown_get_check, which enumerate rather than diagnose.
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 phrase 'one-call health overview' implies this is the aggregate tool to reach for instead of stitching together list/get/metrics calls. It gives clear usage context but never explicitly names an alternative or states when *not* to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single check by token, optionally with the last hour of performance metrics and/or the detailed results of the last 5 requests. updown: GET /api/checks/:token.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | The check's unique token, e.g. ngg8 (from updown_list_checks). | |
| metrics | No | Include performance metrics for the last hour. | |
| results | No | Include detailed results of the last 5 requests (can be large). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered, and the description adds real context beyond them: the fetch is keyed by token and the results flag "can be large," warning about payload size. It still says nothing about error behavior for invalid tokens or pagination.
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 dense sentence plus a short endpoint reference; the core action and the optional enrichments are front-loaded with no filler.
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 no output schema, the description correctly signals what the response can contain (metrics for the last hour, last 5 request results) and flags size risk, which is the right level of detail for a read-only getter. It stops short of noting failure modes for a bad token.
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 three parameters are already documented with equal or greater detail (including the token source example and the size warning). The description largely restates the schema, so the 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?
Specific verb + resource: "Fetch a single check by token," with the endpoint cited. It is distinguishable from updown_list_checks, but it does not explicitly separate itself from the sibling updown_get_check_metrics, which it partially overlaps by offering optional metrics.
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 is only implied through the optional metrics/results flags; there is no explicit when-to-use statement, no exclusion, and no pointer to the metrics-specific sibling that an agent would need to choose correctly between the two.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get aggregated metrics for one check over a time range: uptime, apdex, timings (redirect/namelookup/connection/handshake/response/total, ms) and request counts by response time. Optionally group by 'time' or by 'host' (monitoring location). Data is hourly (daily after 2 days, monthly after 40 days); the range must span at least one hour. Uptime is not returned when grouping. updown: GET /api/checks/:token/metrics.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End time, same formats. Default: now. | |
| from | No | Start time (ISO8601, RFC2822 or YYYY-MM-DD; UTC if no zone). Default: 1 month ago. | |
| group | No | Group results by 'time' or by 'host' (location). | |
| token | Yes | The check's unique token, e.g. ngg8 (from updown_list_checks). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true, so the description carries the burden and it delivers: aggregation granularity rules (hourly, daily after 2 days, monthly after 40 days), the minimum range, and the notable caveat that uptime is not returned when grouping. These are non-obvious behaviors an agent cannot infer from 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?
A single dense paragraph that front-loads what is returned, then grouping, then temporal constraints, plus a compact endpoint reference. Every clause carries information, though the sentence is long and could be split for scannability.
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 no output schema, the description does explain the returned metric set (uptime, apdex, timings, request counts), which is the key gap it must fill, and it flags the uptime/grouping interaction. It does not describe response shape or grouping result structure, leaving a small residual 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?
Schema coverage is 100% (baseline 3), and the description adds real meaning on top: it explains that 'group' means by time bucket or by monitoring location/host, and that metric timings are in milliseconds. It does not restate the from/to format defaults already in the schema, which 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?
States a specific verb+resource ('Get aggregated metrics for one check over a time range') and immediately enumerates the metric families returned. It is clearly distinguishable from sibling read tools like updown_get_check (single check config) and updown_list_downtimes (event list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete usage conditions: the range must span at least one hour, and grouping by 'time' or 'host' is optional. It does not name an alternative sibling (e.g. updown_get_check) or say when this tool is the wrong choice, so it stops short of explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all monitoring checks on the account with their status (down, uptime, last_status, error), period, SSL certificate and domain-expiry info. Optionally filter client-side by status or a text match on URL/alias. updown: GET /api/checks.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Case-insensitive substring to match against the check URL or alias. | |
| status | No | Only checks in this state (default all). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already covering the safety profile, the description adds real behavioral context: the filters are applied client-side (so they don't reduce the fetch), and it enumerates the fields each check carries. It still omits pagination/result-size behavior, but the added detail is substantive.
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, zero filler, with the core list-and-what-it-returns statement front-loaded before the optional filtering detail and the endpoint reference.
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?
Because there is no output schema, the description usefully itemizes the return fields and clarifies filter semantics. It could add pagination or result-volume behavior, but for a simple read-only list tool the essentials are covered.
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 parameter meaning is already documented; notably the description adds the non-obvious fact that both filters operate client-side rather than server-side, which the schema does not convey. This is genuine value beyond the schema text.
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?
States a specific verb and resource ('List all monitoring checks on the account') and enumerates the returned data (status, uptime, last_status, error, period, SSL, domain expiry). This clearly separates it from the singular updown_get_check and the diagnostic updown_find_problems.
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 explains the optional status/search filters and their client-side nature, giving implied usage context, but never states when to prefer this over updown_get_check or updown_find_problems, nor any exclusion or prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the downtimes of one check, newest first, 100 per page: error, started_at, ended_at, duration (seconds) and a details URL. updown: GET /api/checks/:token/downtimes.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page to fetch (100 per page, default 1). | |
| token | Yes | The check's unique token, e.g. ngg8 (from updown_list_checks). | |
| results | No | Include detailed results (last 5 requests before the downtime and recovery). Can be large. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds real behavior beyond that: sort order (newest first), page size, and the shape of each returned record, which helps an agent reason about the response without an output schema.
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 densely packed sentence leads with purpose, then ordering, pagination, and returned fields. The trailing endpoint mapping is marginal but adds a small amount of value; nothing is padded or repeated.
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 no output schema, the description carries the return-value burden and does list the fields returned. Combined with the fully documented input schema and read-only annotation, an agent has enough to invoke it correctly; only pagination termination guidance 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%, so token, page, and results are all documented in the schema itself. The description restates the page size but adds no semantics for the results flag or token format beyond what the schema already provides; 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?
States a specific verb and resource with scope: "List the downtimes of one check". An agent can tell this apart from get_check or find_problems by resource, but no sibling is named as an alternative, so it stops short of full differentiation.
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 is implied rather than stated: you need a check token to list its downtimes. There is no when-to-use guidance, no mention of when to page versus when to stop, and no pointer to a sibling such as find_problems for anomaly-style queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List updown.io's server IP addresses — e.g. to allowlist the monitors in a firewall. Choose all, ipv4 or ipv6. Public — no API key needed. updown: GET /api/nodes/ips, /api/nodes/ipv4, /api/nodes/ipv6.
| Name | Required | Description | Default |
|---|---|---|---|
| family | No | Address family (default all). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds genuinely useful behavioral context: the operation is public and requires no API key. It also maps the call to underlying endpoints, clarifying it is a thin passthrough read. It does not discuss rate limits or response shape, hence not a 5.
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 compact sentences, front-loaded with the purpose before the usage hint and endpoint mapping. Every clause carries information: use case, option set, auth requirement, and API mapping.
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 a single optional enum parameter, no output schema, and readOnlyHint already declared, the definition covers what an agent needs: purpose, auth posture, and option semantics. Return shape is not described, but for a flat IP list it is inferable and no output schema exists to demand it.
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 the enum already enumerates all/ipv4/ipv6, so the description's 'Choose all, ipv4 or ipv6' largely restates schema content. The one addition — that the family selects an address class — is implicit in the enum names themselves, 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?
States a specific verb and resource ('List updown.io's server IP addresses') and immediately scopes it with a concrete use case (firewall allowlisting). It is unmistakably distinct from siblings like updown_list_nodes, which lists monitoring nodes rather than their IPs.
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 supplies a clear triggering context ('e.g. to allowlist the monitors in a firewall') and tells the agent how to select among the family options. There is no explicit when-not guidance or named sibling alternative, which keeps it 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 updown.io's monitoring/webhook servers keyed by location code (lan, mia, tor, rbx, fra, cap, hel, sin, tok, syd) with IPv4, IPv6, city, country and coordinates. Public — no API key needed. updown: GET /api/nodes.
| 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 genuinely useful context beyond that: it is public with no API key required, and it maps to GET /api/nodes. It does not mention rate limits or pagination, but for a static reference listing that is a minor gap.
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?
Dense but front-loaded: what it lists, then the result shape, then the auth note and endpoint. Every clause carries information. Slightly packed with enumerations, but nothing is wasted.
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 no parameters, no output schema, and only a readOnlyHint annotation, the description compensates well by naming the returned attributes (IPv4, IPv6, city, country, coordinates) and the auth model. An agent has enough to call it correctly and interpret the result.
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 takes zero parameters, so the baseline is 4. The description appropriately spends its words describing the output keying (location codes) rather than inventing parameter semantics that do not exist.
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?
States a specific verb ('List') and resource ('updown.io's monitoring/webhook servers') and even enumerates the location keys and returned fields. It is distinguishable from most siblings, but does not address the closely related updown_list_node_ips, whose scope an agent could easily confuse with this one.
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?
There is no explicit when-to-use guidance and no exclusions or named alternatives. Usage is only implied by the subject matter (fetch the location-coded server list). Adequate but leaves the agent to infer the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the alert recipients/channels on the account (email, sms, slack, telegram, webhook, zapier, ...). The id (e.g. email:3719031852) is what check recipients take. updown: GET /api/recipients.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds value beyond that by disclosing the return shape (channel types) and the identifier format (e.g. email:3719031852) that downstream tool calls consume. No pagination or auth detail, but the disclosure of the cross-tool id contract is genuinely useful given there is no output schema.
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 tight sentences: purpose first, then the actionable id detail, then the raw API endpoint as a footnote. No filler and nothing redundant.
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 no output schema, the description must convey what comes back, and it does name the channel types and the id format. It stops short of describing authorization requirements or pagination, but for a simple read-only list it covers what an agent needs to call and consume it.
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?
Zero parameters, so there are no parameter semantics to explain; baseline for a no-arg tool is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('List the alert recipients/channels on the account') and enumerates the channel types returned, which makes it immediately distinguishable from updown_add_recipient. An agent knows exactly what this returns without opening the schema.
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 is implied rather than stated: it notes the `id` is what a check's `recipients` take, which hints this is a discovery step before configuring checks, but there is no explicit when/when-not or named alternative (e.g. versus updown_list_checks).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the account's status pages: token, public URL, name, description, visibility (public/protected/private) and the ordered check tokens shown. updown: GET /api/status_pages.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuinely useful context by naming the fields returned (token, public URL, name, description, visibility, ordered check tokens), but says nothing about pagination, auth requirements, or result size.
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 that lists the returned fields and then names the underlying API endpoint. Every clause 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 no output schema, the description's enumeration of returned fields is the agent's only guide to the response, and it covers it well. Pagination and error/auth behavior are unaddressed but are minor for a small account-level list.
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 takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate beyond the return shape, which it handles.
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?
States a specific verb (List) and resource (the account's status pages), and enumerates the returned fields, which distinguishes it clearly from siblings like updown_create_status_page and updown_update_status_page.
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 is implied by the name and scope, but there is no explicit when-to-use statement or reference to alternatives (e.g., how this relates to get_check or list_checks). For a zero-parameter list tool the inference is easy, so this is adequate rather than strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change a check's settings — URL, period, alias, string match, recipients, headers, locations — or pause/resume it (enabled) or mute its alerts (mute_until). Only the fields you pass are changed. Caution: URLs returned by a read-only key hide basic-auth credentials; re-sending such a URL erases them. Requires the read/write API key. updown: PUT /api/checks/:token.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | New URL to monitor (not for pulse checks). | |
| alias | No | Human-readable name for the check. | |
| token | Yes | The check's unique token, e.g. ngg8 (from updown_list_checks). | |
| period | No | Interval in seconds. Regular checks: 15, 30, 60, 120, 300, 600, 1800 or 3600 (default 60). Pulse checks: anywhere from 15 s to 1 month. | |
| apdex_t | No | APDEX threshold in seconds: 0.125, 0.25, 0.5, 1.0, 2.0, 4.0 or 8.0 (default 0.5). | |
| enabled | No | Whether the check runs. false pauses it (reversible). | |
| http_body | No | HTTP body sent with the request. | |
| http_verb | No | HTTP verb for the request (default GET/HEAD). | |
| published | No | Whether the check's public status page is visible (default false). | |
| mute_until | No | Mute notifications until a time (ISO8601, e.g. 2026-10-01T08:00:00Z), or 'recovery', or 'forever'. | |
| recipients | No | Alert recipient ids to select, e.g. ['email:12345', 'sms:67890'] (from updown_list_recipients). | |
| string_match | No | Text that must appear in the response. For TCP/TCPS checks, '<closed>' inverts the check (alert if the port is open). | |
| custom_headers | No | HTTP headers updown sends with each request, e.g. { "X-Api-Key": "..." }. | |
| disabled_locations | No | Monitoring locations to disable: lan, mia, tor, rbx, fra, cap, hel, sin, tok, syd. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations supply only destructiveHint=true, so the description usefully adds the partial-update contract, the read/write key requirement, the reversibility of pausing, and a concrete data-loss warning that re-sending a credential-masked URL erases basic-auth credentials. It omits any statement of what the call returns or whether updates are idempotent.
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 dense paragraph, front-loaded with the mutation scope, followed by the critical caution and auth note. Every sentence earns its place; only the trailing "updown: PUT /api/checks/:token" endpoint note is arguably filler for an agent.
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 14-parameter destructive mutation with no output schema, the description covers partial semantics, auth, reversibility, and a real credential-loss trap. It would be fully complete with a note on the response (e.g. that the updated check is returned) or behavior on an invalid token.
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 14 well-documented parameters, so the schema already carries the field-level meaning. The description's field list and the enabled/mute_until glosses largely restate what the schema says, adding little beyond 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?
States a specific verb (Change) plus resource (a check's settings) and enumerates the mutable field families (URL, period, alias, string match, recipients, headers, locations) along with the pause/resume and mute behaviors. This clearly separates it from updown_create_check and updown_get_check without needing the schema.
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?
"Only the fields you pass are changed" gives the patch semantics needed to call it correctly, and "Requires the read/write API key" states a precondition absent from the schema. It never names a sibling alternative (e.g. updown_get_check to inspect first), so it falls short of an explicit when/when-not routing statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change a status page's checks (replaces the list, order respected), name, description, visibility or access key. Only the fields you pass are changed. Requires the read/write API key. updown: PUT /api/status_pages/:token.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Name of the status page. | |
| token | Yes | The status page's unique token, e.g. 3ji4k (from updown_list_status_pages). | |
| checks | No | New ordered list of check tokens to show (replaces the current list). | |
| access_key | No | Access key for protected pages (defaults to a random 30-byte string). | |
| visibility | No | Page visibility (default public). | |
| description | No | Text displayed below the name (supports newlines and links). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only destructiveHint=true declared, the description adds real value: it warns that 'checks' replaces the list (with order preserved), clarifies that omitted fields are untouched, and states the read/write API key requirement. This goes meaningfully beyond the annotation, though it doesn't cover failure modes like invalid check tokens.
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 tight sentences: purpose and field list first, then the critical replacement/partial-update semantics and auth requirement, then the API mapping. Every clause earns its place and the most decision-relevant facts are front-loaded.
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 6-parameter mutation tool with no output schema, the definition covers purpose, mutation semantics, and auth. It leaves unspecified what the response contains and how errors (e.g. bad check tokens) surface, which the absence of an output schema makes slightly more relevant.
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, but the description adds semantics the schema doesn't: the partial-update contract ('only the fields you pass are changed') and order significance for the checks list. The remaining parameters are left to the schema, which already documents them well.
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 opens with a specific verb+resource ('Change a status page') and enumerates the exact mutable fields (checks, name, description, visibility, access key). This clearly separates it from siblings like updown_create_status_page and updown_list_status_pages without needing to name 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?
It gives clear context: 'Only the fields you pass are changed' defines partial-update behavior and 'Requires the read/write API key' states a prerequisite. It stops short of explicit when-not-to-use guidance or naming an alternative tool, so it falls just below the top band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
updown_add_recipient1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"updown_create_check1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"updown_create_status_page1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"updown_find_problems1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"updown_get_check1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"updown_get_check_metrics1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"updown_list_checks1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"updown_list_downtimes1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"updown_list_node_ips1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"updown_list_nodes1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"updown_list_recipients1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"updown_list_status_pages1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"updown_update_check1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"updown_update_status_page1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"updown_add_recipientupdown_create_checkupdown_create_status_pageupdown_find_problemsupdown_get_checkupdown_get_check_metricsupdown_list_checksupdown_list_downtimesupdown_list_node_ipsupdown_list_nodesupdown_list_recipientsupdown_list_status_pagesupdown_update_checkupdown_update_status_pageCheck if a website is down, add uptime monitors, read outage history and send test alerts.
Monitor websites, APIs, and servers: create monitors, triage incidents, and query uptime stats.
Uptime monitoring: create and manage HTTP, API, SSL, ping, port and domain checks
Read NodePing checks, uptime, results and events; mute checks, manage maintenance and schedules.
Add one secure layer between your agents and this server.
