Drumbeats MCP
OfficialYou can manage Drumbeats projects and monitors, report job runs, review uptime/incidents, and run standalone HTTP/SSL/DNS checks.
List projects, optionally including notification channels/groups; create or update projects.
Create, list, get, update, pause, and resume cron, heartbeat, basic-job, and HTTP uptime monitors.
Report job starts, successes, and failures with optional run IDs, messages, and payloads.
View monitor history for pings, warnings, checks, and response times; get project uptime/SLA summaries.
List incidents and get, acknowledge, or resolve them, filtered by status or monitor.
Check HTTP URLs, TLS certificates, and DNS records without a Drumbeats account or API key.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Drumbeats MCPCreate a heartbeat monitor for my nightly backup job"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Drumbeats watches cron jobs, background workers and websites. When a job misses its schedule, reports a failure or a site stops answering, it opens an incident and alerts you.
This is the official Model Context Protocol server for Drumbeats. It lets Claude, Cursor, VS Code and other MCP clients work with your account: create monitors, read their history, report job runs and handle incidents. Three of its tools check a website, a certificate or a DNS name and work without an account.
Connect
There are two ways to run it. Both give you the same 19 tools.
Hosted server
Add https://api.drumbeats.io/mcp to your client and sign in with your Drumbeats
account when it asks. Nothing to install and no API key to store.
In Claude, open Settings → Connectors → Add custom connector, paste the URL above and sign in.
In Claude Code:
claude mcp add --transport http drumbeats https://api.drumbeats.io/mcpAdd this to .cursor/mcp.json in your project, or to the global config, and approve
the sign-in on first connect:
{
"mcpServers": {
"drumbeats": {
"url": "https://api.drumbeats.io/mcp"
}
}
}Add this to .vscode/mcp.json in your workspace:
{
"servers": {
"drumbeats": {
"type": "http",
"url": "https://api.drumbeats.io/mcp"
}
}
}Any client that supports Streamable HTTP with OAuth can connect. Give it the URL and it runs the sign-in (OAuth 2.1 with PKCE).
On your machine, with an API key
Create a key at drumbeats.io/account/api-keys. An account key covers every project you own or belong to. A project key limits the server to one project.
Download drumbeats-mcp-vX.Y.Z.mcpb from the
latest release, open it, and
paste your key when Claude Desktop asks.
claude mcp add drumbeats -e DRUMBEATS_API_KEY=dk_your_key -- npx -y @drumbeats/mcp{
"mcpServers": {
"drumbeats": {
"command": "npx",
"args": ["-y", "@drumbeats/mcp"],
"env": { "DRUMBEATS_API_KEY": "dk_your_key" }
}
}
}Add this to .vscode/mcp.json in your workspace:
{
"servers": {
"drumbeats": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@drumbeats/mcp"],
"env": { "DRUMBEATS_API_KEY": "dk_your_key" }
}
}
}Running it with npx needs Node.js 22.
Related MCP server: uptrack-mcp
Tools
The "Needs" column is the permission the tool requires: the scope of your API key, or what you approve when you sign in to the hosted server.
Tool | What it does | Needs |
| Lists the projects you can access, with their alert channels and groups. | read |
| Creates a project. Needs an account key. | manage_projects |
| Changes a project's name or description. | manage_projects |
| Creates a cron, heartbeat or HTTP uptime monitor. | manage_monitors |
| Lists a project's monitors with their type, status and schedule. | read |
| Shows one monitor and its full settings. | read |
| Changes some settings of a monitor and keeps the rest. | manage_monitors |
| Stops a monitor's checks and alerts. | manage_monitors |
| Starts a paused monitor again. | manage_monitors |
Tool | What it does | Needs |
| Reports that a job started and returns a | manage_monitors |
| Reports that a job finished. This is the ping that keeps a monitor up. | manage_monitors |
| Reports that a job failed, which can open an incident and alert. | manage_monitors |
Each takes the monitor's id plus an optional run_id, message and payload. They
do the same as calling the monitor's ping URL, which helps when an agent can't make
outbound HTTP requests, as in Claude Code cloud scheduled tasks.
Tool | What it does | Needs |
| Shows a monitor's recent pings, checks and response times. | read |
| Shows uptime for every monitor in a project. | read |
| Lists incidents, filtered by status or monitor. | read |
| Shows, acknowledges or resolves an incident. | manage_monitors |
Tool | What it does |
| Requests a URL and reports the status code and response time. |
| Reads a site's TLS certificate: whether it is valid, when it expires, who issued it. |
| Looks up a hostname's DNS records. |
These work with no Drumbeats account or key. Add the server through npx without
DRUMBEATS_API_KEY and ask whether your site is up.
Things to ask
List my monitors and tell me which ones are down.
Create a cron monitor for my nightly backup, every day at 02:00 UTC.
What was my uptime over the last 30 days?
Show open incidents and acknowledge the newest one.
Is https://example.com up right now?
When does the certificate for example.com expire?Configuration
These apply when you run the server with npx. The hosted server needs none of them.
Variable | Default | What it does |
| none | Your API key ( |
|
| How long to wait for the Drumbeats API, in milliseconds. |
|
| The API the server talks to. |
Development
Use the Node.js version in .nvmrc.
npm ci # install dependencies
npm run build # compile to dist/
npm run lint # Biome lint and format check
npm test # run the testsCONTRIBUTING.md covers pull requests and RELEASING.md covers releases. Please report security problems privately, as described in SECURITY.md.
License
Apache-2.0. Copyright 2026 Lucky S Software, see NOTICE. Drumbeats is made by Lucky S Software.
Available Tools
19 toolscheck_dnsCheck DNSARead-onlyInspect
Resolve a hostname and report its DNS records (what the domain points to). Works with no Drumbeats account or API key — useful for "what does this domain resolve to?".
| Name | Required | Description | Default |
|---|---|---|---|
| hostname | Yes | The hostname to resolve, e.g. example.com (a domain, not an IP). |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| records | Yes | |
| all_failed | Yes | |
| checked_at | Yes | |
| check_region | Yes | |
| hostname_checked | Yes | |
| resolution_errors | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds value by noting the tool requires no authentication or account, which is important behavioral context for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences that front-load the action and purpose, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (1 parameter, output schema exists), the description provides complete context: what it does, its use case, and authentication requirements.
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 description's mention of hostname resolution does not add meaning beyond the schema's parameter description. 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 resolves a hostname and reports DNS records, with a specific verb 'resolve' and resource 'hostname'. It distinguishes from sibling tools like check_http and check_ssl which perform different checks.
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: works without an account or API key, and gives a use case. However, it does not explicitly state when not to use it or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_httpCheck HTTPARead-onlyInspect
Check whether an http(s) URL is reachable and report its status code and response time. Works with no Drumbeats account or API key — handy for a quick "is this site up?" before signing up.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The http(s) URL to check, e.g. https://example.com | |
| method | No | Request method (default HEAD). | |
| follow_redirects | No | Whether to follow redirects (default true). |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| error | Yes | |
| status | Yes | |
| timing | Yes | |
| final_url | Yes | |
| tls_error | Yes | |
| checked_at | Yes | |
| method_used | Yes | |
| status_code | Yes | |
| check_region | Yes | |
| redirect_chain | Yes | |
| response_time_ms | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely new context: no Drumbeats account or API key is required, and the call returns status code and response time. It does not disclose timeout or failure behavior when the host is unreachable, leaving a small 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?
Two sentences, front-loaded with the action and outcome, followed by the auth-free context. Every clause adds information; nothing is redundant with the title or schema.
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 an output schema present and annotations covering safety and open-world behavior, the description supplies the missing operational context (no auth needed) and the purpose. Only the failure/timeout behavior is left 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 description coverage is 100%, and the schema already documents url, method (default HEAD), and follow_redirects (default true). The description adds no parameter-level detail beyond 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?
States a specific verb and resource ('Check whether an http(s) URL is reachable') and names what it reports (status code, response time). It implicitly separates itself from check_ssl/check_dns by focusing on URL reachability, but never names those siblings, so the differentiation is inferred rather than stated.
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?
Offers one usage scenario ('quick "is this site up?" before signing up') and notes no account is required. It gives no explicit when-not guidance or comparison to the sibling check_ssl/check_dns tools, so an agent must infer which checker to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_sslCheck SSLARead-onlyInspect
Inspect a host's TLS/SSL certificate — validity, expiry date, and issuer. Works with no Drumbeats account or API key — useful for "is my SSL certificate about to expire?".
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | TLS port (default 443). | |
| hostname | Yes | The hostname to inspect, e.g. example.com (no scheme). |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| sans | Yes | |
| error | Yes | |
| valid | Yes | |
| issuer | Yes | |
| subject | Yes | |
| checked_at | Yes | |
| expires_at | Yes | |
| valid_from | Yes | |
| chain_valid | Yes | |
| self_signed | Yes | |
| check_region | Yes | |
| port_checked | Yes | |
| days_remaining | Yes | |
| hostname_match | Yes | |
| hostname_checked | Yes | |
| signature_algorithm | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description doesn't need to restate read-only safety. It adds genuinely new context beyond annotations: the no-account/no-API-key auth model and the specific certificate fields inspected. It doesn't mention rate limits or failure behavior for unresolvable hosts, which keeps it below 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 short sentences, front-loaded with the verb and resource, then the differentiator (no account required) and a concrete motivating use case. Every clause earns its place 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?
The tool is simple (one required param, output schema present), and the description covers purpose, scope of inspection, and auth model. Return values are covered by the output schema, so little is missing; only edge-case behavior (invalid host, timeout) is absent.
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 hostname ('no scheme') and port (default 443) fully documented in the schema. The description adds no parameter-level guidance, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (inspect a host's TLS/SSL certificate) and enumerates what is checked: validity, expiry, issuer. It is clearly distinguishable from the sibling check_http and check_dns by resource, though it never names those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a concrete usage scenario ('is my SSL certificate about to expire?') and the key eligibility fact that no Drumbeats account or API key is needed, which tells the agent it can call this unauthenticated. It stops short of stating when to prefer check_http or other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_monitorCreate monitorAInspect
Create a Drumbeats monitor. One tool for all four types, chosen via "type":
JOB_CRON: a job that should run on a cron schedule (schedule = cron expression).
JOB_BASIC: an event-driven job with no fixed schedule (e.g. triggered by user action). "schedule" is required but ignored for timing — pass any placeholder like "@event". grace_period_seconds and schedule_tolerance don't apply; only failure_tolerance (and, if max_duration_seconds is set, a run-timeout) count against it.
JOB_HEARTBEAT: a passive endpoint your job pings (schedule = expected interval).
UPTIME_HTTP: Drumbeats polls a URL (schedule = poll interval; requires uptime_url). All uptime_* fields are only valid when type is UPTIME_HTTP. Wire alerts at create time with notification_channel_ids / notification_group_ids (UUIDs discoverable via list_projects include=channels,groups). Notification channel types: EMAIL, SLACK, TELEGRAM, DISCORD, WEBHOOK, PAGERDUTY, SMS, PUSH.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Display name for the monitor, shown in the dashboard and in alert notifications. | |
| slug | No | Optional URL-safe identifier, unique within the project (lowercase letters, numbers, hyphens; max 50 chars). Not auto-generated from name — omit to leave unset. Lets you reference the monitor by a stable slug instead of its id. | |
| tags | No | Freeform labels for filtering and grouping monitors in the dashboard (max 10 tags, 50 chars each). | |
| type | Yes | Monitor type — determines how "schedule" is interpreted and what triggers a DOWN transition. JOB_CRON: cron schedule. JOB_BASIC: event-driven, no schedule expectation. JOB_HEARTBEAT: passive endpoint your job pings on an interval. UPTIME_HTTP: Drumbeats polls uptime_url on an interval. See the tool description for details on each. | |
| schedule | Yes | Schedule expression; format depends on type. JOB_CRON: a cron expression (e.g. "0 2 * * *"). JOB_HEARTBEAT and UPTIME_HTTP: an interval string "<number><unit>" with unit s/m/h/d/w (e.g. "5m", "1h") — for JOB_HEARTBEAT this is how often your job must ping in, for UPTIME_HTTP this is the poll interval. JOB_BASIC: required but ignored for timing (JOB_BASIC is event-driven and never goes overdue on a schedule) — pass any non-empty placeholder such as "@event". | |
| timezone | No | IANA timezone (e.g. "UTC", "America/New_York") used to interpret the schedule. Only affects JOB_CRON (cron-tick calculation) — interval-based types (JOB_BASIC, JOB_HEARTBEAT, UPTIME_HTTP) ignore it. Defaults to UTC. | |
| project_id | Yes | The project this monitor belongs to (id from list_projects). | |
| uptime_url | No | The URL Drumbeats polls on the schedule interval. Required when type is UPTIME_HTTP, rejected for job types. Must be http(s) and must not embed credentials (user:pass@host) — put auth in uptime_headers instead. | |
| description | No | Optional human-readable description of what this monitor checks, shown in the dashboard and in alert notifications. | |
| alert_enabled | No | Whether this monitor sends alert notifications at all. Incidents are always recorded regardless. Defaults to true. | |
| uptime_method | No | HTTP method for the check. HEAD is lighter-weight; POST allows sending uptime_request_body. Defaults to GET. | |
| uptime_headers | No | Custom request headers to send (e.g. an API key). Sent on the initial request and on same-origin redirect hops only — stripped on cross-origin redirects so credentials don't leak. Hop-by-hop and connection-control headers (Host, Content-Length, Connection, Transfer-Encoding, etc.) are rejected by the API. | |
| uptime_keyword | No | Substring to search for in the response body (max 1024 chars). If set (and uptime_keyword_absent is false), the check fails when the keyword is missing from an otherwise-successful response. | |
| retention_count | No | Number of most-recent pings (or uptime check results) to retain for this monitor; older ones are pruned. Range 10-1000, defaults to 200. | |
| uptime_locations | No | Check locations for this monitor (beta, all plans — each location consumes 1 beat per check cycle, so a 2-location monitor costs double the beats of a 1-location one). Must include "eu-central"; the API rejects an array missing it, and rejects "us-east" outright if multi-location checking is not enabled for this project. Defaults to ["eu-central"] (today's single-vantage behavior). | |
| failure_tolerance | No | Number of consecutive FAILURE pings (or non-zero exit codes) that transitions the monitor to DOWN and opens a FAILED incident. 1 = alert on the very first failure; 3 = allow 2 failures before alerting. Applies to every monitor type, including JOB_BASIC. Defaults to 1. | |
| uptime_timeout_ms | No | Per-check timeout in milliseconds (1000-30000). Defaults to 10000. | |
| uptime_verify_ssl | No | Whether to reject invalid or self-signed TLS certificates during the check. Set false to allow checking a host with a known-bad cert. Defaults to true. | |
| schedule_tolerance | No | Number of consecutive missed check-ins that transitions the monitor to DOWN and opens a MISSED incident. 1 = alert on the very first miss; 3 = allow 2 misses before alerting. Doesn't apply to JOB_BASIC. Defaults to 1. | |
| uptime_request_body | No | Request body to send when uptime_method is POST (max 10000 chars). Ignored for GET/HEAD. | |
| grace_period_seconds | No | Seconds to wait after the expected check-in time before counting a miss (must be at least 15 — a lower value can trap a monitor in DOWN, since a ping arriving even slightly late would never count as on-time). Doesn't apply to JOB_BASIC (event-driven, no schedule to be late against). Defaults to 300 (5 minutes). | |
| max_duration_seconds | No | If set, a job (not UPTIME_HTTP) that reports a longer duration than this many seconds creates a DURATION_HIGH incident — informational only, does not affect UP/DOWN status. Must be greater than min_duration_seconds if both are set. For JOB_BASIC specifically this also acts as a hard timeout: a run that started (a START ping) but never finished within this many seconds is automatically marked FAILED. | |
| min_duration_seconds | No | If set, a job (not UPTIME_HTTP) that reports a shorter duration than this many seconds creates a DURATION_LOW incident — informational only, does not affect UP/DOWN status. Must be less than max_duration_seconds if both are set. | |
| alert_surge_threshold | No | After this many consecutive alert notifications for this monitor, Drumbeats auto-pauses further notifications for 1 hour (surge protection). Incidents are still recorded either way — this only gates whether a notification is sent. Defaults to 10. | |
| uptime_keyword_absent | No | Flips uptime_keyword's check: when true, the check fails if the keyword IS found. Defaults to false (keyword must be present). | |
| notification_group_ids | No | Notification group ids to alert on incidents (ids from list_projects include=groups). Omitted or empty uses the project's default notification group. | |
| uptime_expected_status | No | HTTP status codes considered "up" (e.g. [200, 201]). Omit or leave empty to use the default: any 2xx response is up. | |
| uptime_follow_redirects | No | Whether to follow HTTP redirects (up to 10 hops; an https→http downgrade redirect is always refused). Defaults to true. | |
| notification_channel_ids | No | Individual notification channel ids to alert directly, in addition to notification_group_ids (ids from list_projects include=channels). |
Output Schema
| Name | Required | Description |
|---|---|---|
| monitor | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=false; the description adds real behavioral context beyond that — alerts are wired at create time, the notification channel type inventory, and which settings are silently ignored per type (JOB_BASIC 'schedule' unused, grace_period/schedule_tolerance not applying). It does not discuss uniqueness conflicts, slug collisions, or error behavior on invalid type/field combinations.
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?
Front-loaded verb, then a tightly organized bulleted enumeration of the four types with the notification guidance trailing. Most sentences earn their place, though the final inventory of notification channel types (EMAIL, SLACK, PAGERDUTY...) is marginal since channels are referenced by UUID discovered elsewhere.
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 29-parameter mutation tool with an output schema and full schema coverage, the description covers the hard part — type-dependent field semantics and alert wiring. Residual gaps are idempotency, slug uniqueness failure modes, and what the response contains, the last of which the output schema handles.
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 satisfied by the schema alone. The description goes further by documenting cross-field conditional semantics that the flat schema cannot express: how 'schedule' is reinterpreted per type, JOB_BASIC's placeholder requirement, failure_tolerance being the only counter for JOB_BASIC, and the uptime_* gating rule.
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 ('Create a Drumbeats monitor') up front, then immediately disambiguates the four monitor types via the 'type' discriminator. An agent can tell this creates a new monitor rather than reading or mutating one, distinct from update_monitor/get_monitor siblings.
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 explicit per-type selection guidance: JOB_CRON for cron schedules, JOB_BASIC for event-driven jobs, JOB_HEARTBEAT for passive pings, UPTIME_HTTP for polling a URL. It also states conditional applicability rules ('All uptime_* fields are only valid when type is UPTIME_HTTP') and points to list_projects include=channels,groups for discovering alert targets. It never explicitly says when to prefer update_monitor instead, so it stops 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.
create_projectCreate projectAInspect
Create a new Drumbeats project. A project groups monitors, incidents, and notification settings. Requires an account-scoped API key with the manage_projects scope. Returns the created project id, which you can then pass to create_monitor. Creating a project may hit your plan's project limit — the result will say so and point to the upgrade path.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The project name. | |
| description | No | Optional project description. |
Output Schema
| Name | Required | Description |
|---|---|---|
| project | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=false and destructiveHint=false, but the description adds substantial context: the required auth scope, that plan project limits may be hit, that the result reports the limit with an upgrade path, and that it returns the created project id. This is well beyond what the structured fields convey.
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 purpose is front-loaded in the first sentence and each subsequent sentence adds value (scope, return, limits). It is slightly long but no sentence is filler; the plan-limit note earns its place as an operational caveat.
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 an output schema existing, the description still summarizes the key return (project id) and its downstream use, and covers auth, limits, and failure messaging. Nothing an agent needs to invoke this correctly 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 both the name and optional description parameters are already documented in the schema. The description adds no parameter-specific syntax or constraints beyond what the schema provides, 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?
States a specific verb and resource ("Create a new Drumbeats project") and immediately defines what a project is ("groups monitors, incidents, and notification settings"), which distinguishes it from sibling creation tools like create_monitor. An agent can tell exactly what this tool produces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the prerequisite (account-scoped API key with manage_projects scope) and the downstream use ("pass to create_monitor"), which clarifies when this tool fits in a workflow. It does not explicitly name when to avoid it, but the ordering guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_monitorGet monitorARead-onlyInspect
Get a single Drumbeats monitor by id, including its type, status, schedule, and alerting metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| monitor_id | Yes | The monitor id (from list_monitors). |
Output Schema
| Name | Required | Description |
|---|---|---|
| monitor | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already declares the safe-read profile, so the description's main added value is naming the record's contents. It says nothing about failure behavior for an unknown or deleted id, or whether archived/paused monitors are still returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, zero filler, with the resource and its return facets front-loaded. Nothing to trim and nothing buried.
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 one-param read tool with an output schema and a readOnlyHint, the description covers what is needed to invoke it correctly. Only the not-found/invalid-id case is left unaddressed, a minor gap at this 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?
With a single parameter at 100% schema coverage and an explicit 'from list_monitors' hint in the schema, the schema carries the semantics. The description's 'by id' restates rather than extends it, 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?
States a specific verb ('Get') and resource ('a single Drumbeats monitor by id'), and enumerates the returned facets (type, status, schedule, alerting metadata). The word 'single' plus the id requirement cleanly separates it from list_monitors and get_monitor_history.
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: fetch one monitor's full record when you already have its id (the schema note points to list_monitors as the source). There is no explicit when-to-use/when-not statement and no sibling is named in the description itself, so the agent must infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_monitor_historyGet monitor historyARead-onlyInspect
Fetch a monitor's recent history. One tool with a "kind" argument: pings | warnings | checks | response_times. Defaults to pings. Use it to answer "what happened with this monitor lately?".
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Which history to fetch: pings (job check-ins, paginated), warnings (JOB_BASIC ping-hygiene issues), checks (latest uptime check result), response_times (uptime response-time statistics). | pings |
| page | No | Page number for kind=pings (default 1). | |
| limit | No | Page size for kind=pings (max 100, default 20). | |
| monitor_id | Yes | The monitor id (from list_monitors). | |
| period_hours | No | Look-back window in hours for kind=response_times (default 24). |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| kind | Yes | |
| monitor_id | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already declares this is a safe read, and an output schema exists, so the description's burden is light. It adds the pings default and the fact that all four histories come from one tool, but says nothing about pagination behavior, retention window, or empty-result behavior beyond what annotations and schema already convey. Effectively redundant with the schema's own kind documentation.
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, purpose first, the kind enumerations second, the motivating question last. No filler and nothing important buried.
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 an output schema present and 100% parameter coverage, the description is sufficient for correct invocation. The only gap is sibling differentiation against get_uptime_summary and list_incidents, which matters in a toolset this dense but is not required to call this 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 description coverage is 100% and the kind enum is documented in detail in the schema (including pagination scope for page/limit and period_hours applicability), so the schema does the heavy lifting. The description only restates the kind values and the pings default, adding no semantics beyond the schema. 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?
"Fetch a monitor's recent history" is a specific verb+resource, and the enumeration of the four kinds (pings | warnings | checks | response_times) tells the agent exactly what data families are reachable. It does not explicitly distinguish itself from the related get_uptime_summary or list_incidents siblings, which keeps it below a 5.
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?
"Use it to answer 'what happened with this monitor lately?'" implies the intended query shape but gives no when-not conditions and never names the alternative sibling tools (e.g. get_uptime_summary for aggregates, list_incidents for incident records). Usage is inferable but not routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_uptime_summaryGet uptime summaryARead-onlyInspect
Get the project-level uptime / SLA summary across all of a project's uptime monitors: overall uptime percentage plus per-monitor uptime, check counts, and response times over a look-back window. The answer to "what is my uptime this month?".
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | The project to summarize uptime for (from list_projects). | |
| period_hours | No | Look-back window in hours (default 24). Use 720 for roughly "this month". |
Output Schema
| Name | Required | Description |
|---|---|---|
| overall | No | |
| monitors | No | |
| period_hours | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe read, and the description adds the useful scoping fact that results span all monitors in a project over a look-back window. Beyond that it mostly restates return fields that the output schema already documents, and it says nothing about cost, latency, or limits on large projects.
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?
Front-loaded with the core action and scope in the first clause, and the tagline is a compact usage anchor. The middle list of return fields slightly duplicates the output schema and could be trimmed.
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 read-only two-parameter aggregation with an output schema, the description covers scope, window, and intent well enough to call correctly. Nothing critical is missing, though a note on how it differs from get_monitor_history would close the last 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% and both parameters are documented, including the 720-hours-equals-a-month mapping, so the schema does the heavy lifting. The description only echoes the look-back window concept without adding format or edge-case detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get) and resource (project-level uptime/SLA summary across all uptime monitors) and enumerates what comes back: overall percentage, per-monitor uptime, check counts, response times. That project-wide aggregation vs. the sibling get_monitor_history (single-monitor history) is clear from the wording.
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 tagline "what is my uptime this month?" plus the schema hint to use 720 hours gives clear situational context for when to reach for this tool. No explicit when-not or named alternative (e.g. get_monitor_history for a single monitor) is stated, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_incidentsList incidentsARead-onlyInspect
List incidents for a Drumbeats project (downtime / missed-run events), newest first and paginated. Requires a project_id from list_projects. Filter by status (OPEN, ACKNOWLEDGED, RESOLVED) or a single monitor.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1). | |
| limit | No | Page size (max 200, default 20). | |
| status | No | Filter by incident status. | |
| monitor_id | No | Filter to a single monitor. | |
| project_id | Yes | The project to list incidents for (from list_projects). |
Output Schema
| Name | Required | Description |
|---|---|---|
| incidents | Yes | |
| pagination | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes that this is a safe read operation, so the description adds value with ordering ('newest first') and pagination behavior. It does not discuss return shape or limits beyond pagination, but the output schema covers return details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences with zero waste, front-loading the core purpose and then the required prerequisite and filtering options.
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 a read-only list tool with full schema coverage, annotations, and an output schema, the description covers everything needed: what it lists, ordering, pagination, the required project_id, and available filters.
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 parameter meaning is already fully documented in the schema. The description mostly repeats existing schema details (status enum values, single-monitor filtering) and adds little beyond that, making the baseline 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 uses a specific verb ('List') and resource ('incidents'), and further pins the resource as 'downtime / missed-run events' for a Drumbeats project. This distinguishes it clearly from sibling tools such as get_monitor_history and get_uptime_summary.
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 explicitly states the prerequisite ('Requires a project_id from list_projects') and explains filtering by status or a single monitor, which gives the agent clear context for correct invocation. It does not name when to choose this over a specific alternative, so it falls short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_monitorsList monitorsARead-onlyInspect
List all monitors in a Drumbeats project (jobs and uptime checks), with their type, status, and schedule metadata. Requires a project_id from list_projects. Use it to find a monitor id before fetching details, history, or incidents.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | The project to list monitors for. Obtain the id from list_projects (an account key spans many projects). |
Output Schema
| Name | Required | Description |
|---|---|---|
| monitors | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds useful context: the project scoping dependency, the monitor subtypes, and the returned metadata fields. It does not discuss pagination or result-size limits, which is a modest gap for a list tool with 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?
Two sentences, no filler, with purpose, prerequisite, and follow-up routing each in its own clause. The most important detail (list all monitors) is 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 single-parameter read tool with an output schema and readOnlyHint annotation, the description covers purpose, prerequisite, subtypes, and downstream usage. Return values need not be explained because the output schema exists.
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% and the project_id parameter already documents that the id comes from list_projects and that an account key spans many projects. The description repeats the same prerequisite but adds no new syntax, format, or validity detail 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 names a specific verb and resource ('List all monitors in a Drumbeats project'), clarifies scope by enumerating what a monitor is ('jobs and uptime checks'), and states the returned fields ('type, status, and schedule metadata'). It is clearly distinguishable from siblings like get_monitor, get_monitor_history, and 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?
It gives explicit prerequisites ('Requires a project_id from list_projects') and a concrete use case ('Use it to find a monitor id before fetching details, history, or incidents'), pointing the agent to downstream sibling tools. When to use this versus get_monitor or get_monitor_history is implicit in that routing statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_projectsList projectsARead-onlyInspect
List all Drumbeats projects the configured account API key can access. Returns each project id, name, plan, and basic metadata — use it to find the target project id before creating or querying monitors. Pass include=["channels","groups"] to also return each project's notification channels and groups, whose ids are needed to wire alerts when creating a monitor.
| Name | Required | Description | Default |
|---|---|---|---|
| include | No | Optionally also fetch, per project, its notification channels and/or groups. Their ids are needed to wire alerts when creating a monitor. |
Output Schema
| Name | Required | Description |
|---|---|---|
| projects | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered; the description adds meaningful behavior beyond that — it says results are scoped to the API key's accessible projects and that include triggers an additional per-project fetch of channels and groups. It doesn't mention pagination or result-size limits, which keeps it from 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 sentences, front-loaded with what it returns, followed by the primary use case and the optional expansion. No filler and nothing redundant with the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A simple, zero-required-parameter read tool with an output schema that already documents return shape. The description covers scope, return summary, purpose, and the one optional parameter's downstream value — everything needed to call 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?
Schema coverage is 100%, so baseline is 3, but the description goes further by explaining why the expansion matters — channel and group ids are needed to wire alerts when creating a monitor. That is intent-level meaning the schema description only partially echoes.
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 Drumbeats projects') plus the access scope ('the configured account API key can access'), which no sibling tool covers. It also previews the returned fields (project id, name, plan, basic metadata), so an agent can tell it apart from list_monitors or get_uptime_summary 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?
Gives a clear downstream use case: find the target project id before creating or querying monitors. That is real routing guidance, but there is no explicit 'when not to use' or named alternative sibling (e.g., when to prefer get_monitor instead), so it stops short of the 5 bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
manage_incidentManage incidentAIdempotentInspect
Triage a Drumbeats incident: get its details, acknowledge it, or resolve it. One tool with an "action" argument.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | get = fetch incident details; acknowledge = mark it as being worked on; resolve = close it. | get |
| incident_id | Yes | The incident id (from list_incidents). |
Output Schema
| Name | Required | Description |
|---|---|---|
| action | Yes | |
| incident | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag readOnlyHint=false and idempotentHint=true, so the description's job is to add mutation context — but it adds nothing beyond restating the schema's action list. It never says what 'resolve' actually changes (state, notifications to responders, whether it can be undone) or whether acknowledge/resolve require specific permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, both front-loaded: the verb+resource first, the single-tool/multi-action design second. Nothing redundant given the schema is the reference for the action enum.
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 only two parameters, an output schema present, and annotations covering safety, the definition is nearly self-sufficient for selection and invocation. The remaining gap is behavioral: an agent still doesn't know the side effects or preconditions of acknowledge/resolve.
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 descriptions already define get/acknowledge/resolve, so the description can only repeat it. The only added hint is that incident_id comes from list_incidents, which the schema already states — no new syntax or format detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific resource (a Drumbeats incident) and enumerates the exact operations available: fetch details, acknowledge, resolve. The agent can tell immediately this is the single-incident triage tool, distinct from list_incidents in the sibling set.
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 framing 'Triage a Drumbeats incident' plus the action list gives clear context for when to call it, and the enum descriptions map each action to a situation. It stops short of naming alternatives (e.g., 'use list_incidents to find the id') or stating exclusions, so it's clear but not fully routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pause_monitorPause monitorAIdempotentInspect
Pause a monitor by id. It stops running checks and sending alerts until resumed.
| Name | Required | Description | Default |
|---|---|---|---|
| monitor_id | Yes | The monitor id (from list_monitors). |
Output Schema
| Name | Required | Description |
|---|---|---|
| monitor | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description explains the operational effect: checks stop and alerts are suppressed until the monitor is resumed. This adds useful behavioral context, although it does not cover permissions, behavior when already paused, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted text. The core action and its effect are front-loaded and immediately clear.
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 one-parameter mutation tool with annotations and an output schema, the description provides enough context to invoke it correctly. It explains the pause effect and reversibility, though it could explicitly point to resume_monitor for resuming.
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 only parameter is monitor_id, and the schema already documents it fully, including that it comes from list_monitors. The description's phrase 'by id' adds little beyond the schema, so the high schema coverage justifies a baseline score.
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 resource: 'Pause a monitor by id.' It clearly distinguishes pausing from related monitor operations such as resume, get, update, and create, though it does not explicitly name the resume_monitor sibling.
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 the tool by explaining that it stops checks and alerts until resumed, but it does not explicitly state when to choose it over alternatives or any preconditions. The usage context is understandable but not fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ping_failurePing: run failedAInspect
Tell Drumbeats a monitored job failed. This marks the run failed and can open an incident and send alerts. Replaces a curl to the ping URL, so it works where outbound HTTP needs an allowlist (e.g. Claude Code cloud scheduled tasks).
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | No | Pairs a start with its success/failure so Drumbeats can time the run. Reuse the run_id ping_start returned. | |
| message | No | Optional short note stored with the ping, e.g. "processed 120 rows". | |
| payload | No | Optional longer text stored as the ping payload, e.g. a log tail or error output (first 10 KB kept). | |
| monitor_id | Yes | The monitor UUID — the same id as in its ping URL (from list_monitors). |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| event | Yes | |
| run_id | Yes | |
| ping_id | Yes | |
| recorded | Yes | |
| timestamp | Yes | |
| monitor_id | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses meaningful side effects: marking the run failed, potentially opening an incident, and sending alerts. The allowlist/curl-replacement note adds useful operational context. It does not fully explain conditions under which incidents or alerts are triggered, but it is substantially transparent for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences with the core action front-loaded. Each sentence contributes useful information: purpose, side effects, and the practical allowlist rationale.
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?
An output schema exists and the input schema has full parameter coverage, so return values and parameters need not be repeated. The description supplies the key behavioral context for a mutation tool with side effects, leaving no major gap for correct invocation.
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%, and the schema already documents run_id, message, payload, and monitor_id in detail. The description adds no parameter-specific meaning beyond that, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: telling Drumbeats that a monitored job failed. It clearly distinguishes this from the success/start siblings by naming the failed-run outcome and its consequences.
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 for when to use the tool: reporting a failed monitored job, including scheduled-task environments where direct HTTP is restricted. It does not explicitly name ping_start or ping_success as alternatives, so it stops short of full when-to-use routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ping_startPing: run startedAInspect
Tell Drumbeats a monitored job just started. Returns a run_id; pass it to ping_success or ping_failure when the job ends so the run is timed. Replaces a curl to the ping URL, so it works where outbound HTTP needs an allowlist (e.g. Claude Code cloud scheduled tasks).
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | No | Pairs a start with its success/failure so Drumbeats can time the run. Reuse the run_id ping_start returned. | |
| message | No | Optional short note stored with the ping, e.g. "processed 120 rows". | |
| payload | No | Optional longer text stored as the ping payload, e.g. a log tail or error output (first 10 KB kept). | |
| monitor_id | Yes | The monitor UUID — the same id as in its ping URL (from list_monitors). |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| event | Yes | |
| run_id | Yes | |
| ping_id | Yes | |
| recorded | Yes | |
| timestamp | Yes | |
| monitor_id | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the non-read-only, non-idempotent, non-destructive profile, and the description adds the key behavioral facts: it returns a run_id, that run_id governs run timing, and it exists as an allowlist-friendly substitute for outbound HTTP. It stops short of stating auth requirements or what happens if a run is started and never closed.
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, each earning its place: purpose first, the run_id contract second, the deployment rationale last. No filler and nothing buried.
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?
An output schema exists, so return values needn't be explained, and all four parameters are covered by the schema. The remaining gap is minor: no guidance on what an unclosed run does to timing or whether run_id should be omitted on first call (the schema implies it, but the description is silent).
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 run_id, message, payload, and monitor_id are all documented in the schema, including the run_id pairing rule. The description reinforces the run_id lifecycle but adds no format or constraint detail beyond what the schema already provides, 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?
States a specific verb and resource ("Tell Drumbeats a monitored job just started") and immediately positions itself relative to ping_success and ping_failure. An agent can distinguish it from every sibling 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?
Names the exact trigger (job start), the follow-up path (pass run_id to ping_success/ping_failure when the job ends), and even the alternative it replaces (a curl to the ping URL) with the condition that selects this tool — environments where outbound HTTP needs an allowlist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ping_successPing: run succeededAInspect
Tell Drumbeats a monitored job finished successfully. This is the heartbeat that keeps the monitor up. Replaces a curl to the ping URL, so it works where outbound HTTP needs an allowlist (e.g. Claude Code cloud scheduled tasks).
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | No | Pairs a start with its success/failure so Drumbeats can time the run. Reuse the run_id ping_start returned. | |
| message | No | Optional short note stored with the ping, e.g. "processed 120 rows". | |
| payload | No | Optional longer text stored as the ping payload, e.g. a log tail or error output (first 10 KB kept). | |
| monitor_id | Yes | The monitor UUID — the same id as in its ping URL (from list_monitors). |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| event | Yes | |
| run_id | Yes | |
| ping_id | Yes | |
| recorded | Yes | |
| timestamp | Yes | |
| monitor_id | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (non-read-only, non-destructive, not idempotent), so the description's job is to add semantics — and it does, explaining this is the heartbeat whose absence would let the monitor fall over, plus the network-transport constraint (allowlisted outbound HTTP). It does not mention the consequence for incident/alert state or that repeated pings are not deduplicated.
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, front-loaded with what it does, then the operational rationale, then the transport caveat. No sentence is redundant with the title or restates structured fields.
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 an output schema, full annotation coverage, and 100% parameter documentation, the description only needs to orient the agent — which it does. The one missing piece is the cross-tool workflow (pair with `ping_start`'s run_id to time a run), which the schema implies but the description never reinforces.
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 four parameters (including the run_id pairing and payload truncation) are already documented in the schema. The description adds no parameter-level meaning beyond referencing the 'ping URL' and monitor identity, 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?
States a specific verb and resource ('Tell Drumbeats a monitored job finished successfully') plus the outcome 'successfully', which implicitly separates it from the sibling `ping_failure`. It never names the siblings explicitly, so the differentiation is inferable rather than spelled out.
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?
"Replaces a curl to the ping URL, so it works where outbound HTTP needs an allowlist" gives a concrete situation that selects this tool, and 'keeps the monitor up' explains the ongoing obligation. It stops short of stating exclusions (e.g. use `ping_failure` on error, `ping_start` first for timing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resume_monitorResume monitorAIdempotentInspect
Resume a paused monitor by id.
| Name | Required | Description | Default |
|---|---|---|---|
| monitor_id | Yes | The monitor id (from list_monitors). |
Output Schema
| Name | Required | Description |
|---|---|---|
| monitor | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read-only but idempotent operation, and the description adds the useful precondition that the monitor must be paused. It does not disclose behavior if the monitor is not paused, required permissions, or any side effects beyond resuming monitoring, leaving some behavioral context implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the action, target, and required identifier immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has a fully documented single parameter, includes annotations, and has an output schema, so the description does not need to explain return values. It is nearly complete, though it could mention what happens when the monitor is not paused or whether permissions are required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single parameter is fully documented in the schema as the monitor id from list_monitors. The description only repeats "by id" and adds no further semantics beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ("Resume a paused monitor") and includes the id-based targeting. It is clear enough to distinguish the operation from general monitor updates, but it does not explicitly name the sibling tool it complements or contrasts with, such as pause_monitor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the phrase "paused monitor," so an agent can infer this applies only to paused monitors. However, the description provides no explicit when-to-use guidance, no when-not-to-use conditions, and no alternatives for monitors that are not paused.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_monitorUpdate monitorAIdempotentInspect
Update an existing Drumbeats monitor. Provide monitor_id plus only the fields to change. Set status to PAUSED or UP to pause/resume (or use pause_monitor / resume_monitor). The uptime_* fields apply to UPTIME_HTTP monitors.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | New display name for the monitor. | |
| slug | No | New URL-safe identifier, unique within the project (lowercase letters, numbers, hyphens; max 50 chars). Pass null to clear. | |
| tags | No | New tag list (max 10 tags, 50 chars each). Fully replaces the existing tags, not merged — include every tag you want kept. | |
| type | No | Change the monitor's type. Switching type recalculates the schedule (next_expected_at) and gates which fields apply — uptime_* fields become required/rejected based on the resulting type. Rarely changed after creation. | |
| status | No | Manually set status. UP forces recovery — resets consecutive_failures, consecutive_misses, and consecutive_alerts to 0, even if the monitor has not actually recovered. PAUSED stops checks/alerts without resetting counters. For the common pause/resume flow, prefer pause_monitor / resume_monitor. | |
| schedule | No | New schedule expression; format depends on the (possibly also-updated) type — see create_monitor's schedule field for the per-type format. Changing it recalculates next_expected_at and resets the schedule anchor for JOB_HEARTBEAT/UPTIME_HTTP. | |
| timezone | No | New IANA timezone (e.g. "UTC", "America/New_York"). Only affects JOB_CRON schedule interpretation. | |
| monitor_id | Yes | The monitor id to update (from list_monitors). | |
| uptime_url | No | New URL to poll. Only allowed when the monitor's type is (or is being changed to) UPTIME_HTTP. Must be http(s) and must not embed credentials (user:pass@host) — put auth in uptime_headers instead. | |
| description | No | New description (max 500 chars). Pass null to clear. | |
| alert_enabled | No | Whether this monitor sends alert notifications at all. | |
| uptime_method | No | HTTP method for the check (UPTIME_HTTP only). HEAD is lighter-weight; POST allows uptime_request_body. | |
| uptime_headers | No | Custom request headers (UPTIME_HTTP only). Stripped on cross-origin redirects; hop-by-hop/connection headers are rejected by the API. Pass null to clear. | |
| uptime_keyword | No | Substring to search for in the response body (UPTIME_HTTP only, max 1024 chars). Pass null to clear. | |
| retention_count | No | Number of most-recent pings/check-results to retain (10-1000); older ones are pruned. | |
| uptime_locations | No | New check locations (UPTIME_HTTP only, beta). Fully replaces the existing list. Must include "eu-central"; each location consumes 1 beat per check cycle. The API rejects "us-east" if multi-location checking is not enabled for this project. | |
| failure_tolerance | No | Number of consecutive FAILURE pings before transitioning to DOWN (1 = alert on the very first failure). Applies to every monitor type, including JOB_BASIC. | |
| uptime_timeout_ms | No | Per-check timeout in milliseconds, 1000-30000 (UPTIME_HTTP only). | |
| uptime_verify_ssl | No | Whether to reject invalid/self-signed TLS certificates during the check (UPTIME_HTTP only). | |
| schedule_tolerance | No | Number of consecutive missed check-ins before transitioning to DOWN (1 = alert on the very first miss). Ignored for JOB_BASIC. | |
| uptime_request_body | No | Request body sent when uptime_method is POST (UPTIME_HTTP only, max 10000 chars). Pass null to clear. | |
| grace_period_seconds | No | Seconds to wait after the expected check-in time before counting a miss (must be at least 15). Ignored for JOB_BASIC. | |
| max_duration_seconds | No | If set, a job (not UPTIME_HTTP) reporting a longer duration than this creates a DURATION_HIGH incident (informational only). Must be greater than min_duration_seconds if both are set. For JOB_BASIC this also acts as a hard timeout on started-but-unfinished runs. Pass null to clear. | |
| min_duration_seconds | No | If set, a job (not UPTIME_HTTP) reporting a shorter duration than this creates a DURATION_LOW incident (informational only). Must be less than max_duration_seconds if both are set. Pass null to clear. | |
| alert_surge_threshold | No | After this many consecutive alert notifications, Drumbeats auto-pauses further notifications for 1 hour (incidents keep recording regardless). | |
| uptime_keyword_absent | No | Flips uptime_keyword's check: true means the check fails if the keyword IS found (UPTIME_HTTP only). | |
| notification_group_ids | No | Notification group ids to alert on incidents (ids from list_projects include=groups). Fully replaces the existing list, not merged — omitted or empty falls back to the project's default group. | |
| uptime_expected_status | No | HTTP status codes considered "up" (UPTIME_HTTP only). Empty means the default: any 2xx response is up. | |
| uptime_follow_redirects | No | Whether to follow HTTP redirects, up to 10 hops (UPTIME_HTTP only). | |
| notification_channel_ids | No | Individual notification channel ids to alert directly (ids from list_projects include=channels). Fully replaces the existing list, not merged. |
Output Schema
| Name | Required | Description |
|---|---|---|
| monitor | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and idempotentHint=true, so the safety profile is covered. The description adds genuinely useful behavior: patch-style partial updates and the fact that uptime_* fields only apply to UPTIME_HTTP. It does not warn that changing 'type' recalculates schedules or that status=UP force-resets counters — that detail lives only in the 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?
Four short sentences, front-loaded with the core action and the required parameter, then progressively narrower routing and scoping notes. No filler and nothing redundant with the schema.
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 30 parameters, an output schema, and strong annotations, the description needs to supply orientation rather than field detail — it does so via patch semantics, the sibling routing, and the uptime_* gate. A note on the riskiness of changing 'type' and the force-recovery semantics of status=UP would close the remaining 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%, so the baseline is 3; the description goes beyond by consolidating two cross-cutting parameter rules: patch semantics for all fields, and the type-gating of the uptime_* family. That is real meaning the schema only conveys field-by-field.
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 ('update') and resource ('an existing Drumbeats monitor') and distinguishes itself from pause_monitor/resume_monitor. It stops short of distinguishing from create_monitor, though the 'existing' qualifier does most of that work.
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 clear invocation guidance: pass monitor_id plus only the fields to change (partial-update semantics), and routes the common pause/resume flow to pause_monitor / resume_monitor. It does not say anything about when not to use this tool (e.g. type changes being rare, which is buried in the schema).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_projectUpdate projectAIdempotentInspect
Update an existing Drumbeats project. Provide project_id plus only the fields to change (name and/or description). Requires an API key with the manage_projects scope and MANAGER or OWNER role on the project.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | New project name. | |
| project_id | Yes | The project id to update (from list_projects). | |
| description | No | New project description (null to clear). |
Output Schema
| Name | Required | Description |
|---|---|---|
| project | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety and idempotency (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description adds genuinely new behavioral context: the manage_projects scope and MANAGER/OWNER role prerequisite, plus partial-update semantics. It does not say what happens if no mutable field is supplied, but that is a minor gap under the lower annotation-adjusted bar.
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 purpose, then invocation pattern, then prerequisites. No repetition of schema field names or annotation restatement.
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?
An output schema exists, so return values need no explanation, and auth requirements are fully stated. Only edge cases (empty update payload, failure modes) are unaddressed, which is a small gap for a three-parameter mutation.
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, and the description earns a bump by clarifying that omitted fields are left unchanged — semantics the schema does not convey. Field names and clearing behavior (description null) are left to 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 and resource ("Update an existing Drumbeats project") and names the mutable fields, making it clearly distinct from create_project and list_projects. It stops short of explicitly naming siblings, but the update-vs-create distinction is unambiguous.
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 invocation guidance: supply project_id plus only the fields to change, which tells the agent how to perform a partial update rather than a full replace. It also states the required API key scope and project role, though it never names an alternative tool or a when-not case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
18 tool updates
v0.5.1- Changed
check_http14 fields changed- removed
Output schema / properties / error / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / error / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / timing / properties / connect_ms / anyOfRemoved value: -[ - { - "type": "number" - }, - { - "type": "null" - } -] - added
Output schema / properties / timing / properties / connect_ms / typeAdded value: +[ + "number", + "null" +] - removed
Output schema / properties / timing / properties / dns_ms / anyOfRemoved value: -[ - { - "type": "number" - }, - { - "type": "null" - } -] - added
Output schema / properties / timing / properties / dns_ms / typeAdded value: +[ + "number", + "null" +] - removed
Output schema / properties / timing / properties / download_ms / anyOfRemoved value: -[ - { - "type": "number" - }, - { - "type": "null" - } -] - added
Output schema / properties / timing / properties / download_ms / typeAdded value: +[ + "number", + "null" +] - removed
Output schema / properties / timing / properties / tls_ms / anyOfRemoved value: -[ - { - "type": "number" - }, - { - "type": "null" - } -] - added
Output schema / properties / timing / properties / tls_ms / typeAdded value: +[ + "number", + "null" +] - removed
Output schema / properties / timing / properties / ttfb_ms / anyOfRemoved value: -[ - { - "type": "number" - }, - { - "type": "null" - } -] - added
Output schema / properties / timing / properties / ttfb_ms / typeAdded value: +[ + "number", + "null" +] - removed
Output schema / properties / tls_error / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / tls_error / typeAdded value: +[ + "string", + "null" +]
- Changed
check_ssl12 fields changed- removed
Output schema / properties / error / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / error / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / expires_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / expires_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / issuer / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / issuer / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / signature_algorithm / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / signature_algorithm / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / subject / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / subject / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / valid_from / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / valid_from / typeAdded value: +[ + "string", + "null" +]
- Changed
create_monitor20 fields changed- removed
Output schema / properties / monitor / properties / alert_enabled / anyOfRemoved value: -[ - { - "type": "boolean" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / alert_enabled / typeAdded value: +[ + "boolean", + "null" +] - removed
Output schema / properties / monitor / properties / created_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / created_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / description / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / description / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / last_success_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / last_success_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / next_expected_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / next_expected_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / project_id / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / project_id / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / slug / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / slug / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / status / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / status / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / timezone / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / timezone / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / type / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / type / typeAdded value: +[ + "string", + "null" +]
- Changed
create_project8 fields changed- removed
Output schema / properties / project / properties / created_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / project / properties / created_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / project / properties / description / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / project / properties / description / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / project / properties / owner_email / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / project / properties / owner_email / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / project / properties / plan / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / project / properties / plan / typeAdded value: +[ + "string", + "null" +]
- Changed
get_monitor20 fields changed- removed
Output schema / properties / monitor / properties / alert_enabled / anyOfRemoved value: -[ - { - "type": "boolean" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / alert_enabled / typeAdded value: +[ + "boolean", + "null" +] - removed
Output schema / properties / monitor / properties / created_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / created_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / description / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / description / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / last_success_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / last_success_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / next_expected_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / next_expected_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / project_id / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / project_id / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / slug / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / slug / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / status / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / status / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / timezone / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / timezone / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / type / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / type / typeAdded value: +[ + "string", + "null" +]
- Changed
get_monitor_history1 field changed- changed
Output schema / properties / data / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "data": { - "items": { - "additionalProperties": false, - "properties": { - "created_at": { - "type": "string" - }, - "duration_assertion": { - "anyOf": [ - { - "enum": [ - "PASS", - "TOO_FAST", - "TOO_SLOW" - ], - "type": "string" - }, - { - "type": "null" - } - ] - }, - "duration_ms": { - "anyOf": [ - { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - { - "type": "null" - } - ] - }, - "event": { - "enum": [ - "START", - "SUCCESS", - "FAILURE", - "LOG" - ], - "type": "string" - }, - "exit_code": { - "anyOf": [ - { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - { - "type": "null" - } - ] - }, - "id": { - "type": "string" - }, - "message": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "payload": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "payload_bytes": { - "anyOf": [ - { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - { - "type": "null" - } - ] - }, - "payload_truncated": { - "type": "boolean" - }, - "request_ip": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "request_ua": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "run_id": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "started_at": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - } - }, - "required": [ - "id", - "run_id", - "event", - "exit_code", - "duration_ms", - "duration_assertion", - "message", - "payload", - "payload_truncated", - "payload_bytes", - "request_ip", - "request_ua", - "started_at", - "created_at" - ], - "type": "object" - }, - "type": "array" - }, - "pagination": { - "additionalProperties": false, - "properties": { - "has_next": { - "type": "boolean" - }, - "has_prev": { - "type": "boolean" - }, - "limit": { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - "page": { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - "total": { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - "total_pages": { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - } - }, - "required": [ - "page", - "limit", - "total", - "total_pages", - "has_next", - "has_prev" - ], - "type": "object" - } - }, - "required": [ - "data", - "pagination" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "analyzed_period": { - "additionalProperties": false, - "properties": { - "from": { - "type": "string" - }, - "to": { - "type": "string" - }, - "total_pings": { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - } - }, - "required": [ - "from", - "to", - "total_pings" - ], - "type": "object" - }, - "warnings": { - "items": { - "additionalProperties": false, - "properties": { - "affected_count": { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - "message": { - "type": "string" - }, - "recommendation": { - "type": "string" - }, - "type": { - "enum": [ - "MISSING_RUN_ID", - "MISSING_START" - ], - "type": "string" - } - }, - "required": [ - "type", - "message", - "affected_count", - "recommendation" - ], - "type": "object" - }, - "type": "array" - } - }, - "required": [ - "warnings", - "analyzed_period" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "check_region": { - "type": "string" - }, - "check_status": { - "enum": [ - "ok", - "probe_error" - ], - "type": "string" - }, - "created_at": { - "type": "string" - }, - "cycle_id": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "error": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "id": { - "type": "string" - }, - "is_up": { - "type": "boolean" - }, - "monitor_id": { - "type": "string" - }, - "response_time_ms": { - "type": "number" - }, - "ssl_expires_at": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "ssl_issuer": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "status_code": { - "anyOf": [ - { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - { - "type": "null" - } - ] - } - }, - "required": [ - "id", - "monitor_id", - "status_code", - "response_time_ms", - "is_up", - "error", - "ssl_expires_at", - "ssl_issuer", - "check_region", - "check_status", - "created_at" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "avg_ms": { - "anyOf": [ - { - "type": "number" - }, - { - "type": "null" - } - ] - }, - "down_count": { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - "max_ms": { - "anyOf": [ - { - "type": "number" - }, - { - "type": "null" - } - ] - }, - "min_ms": { - "anyOf": [ - { - "type": "number" - }, - { - "type": "null" - } - ] - }, - "p95_ms": { - "anyOf": [ - { - "type": "number" - }, - { - "type": "null" - } - ] - }, - "total_checks": { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - "up_count": { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - "uptime_percentage": { - "type": "number" - } - }, - "required": [ - "avg_ms", - "min_ms", - "max_ms", - "p95_ms", - "total_checks", - "up_count", - "down_count", - "uptime_percentage" - ], - "type": "object" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "data": { + "items": { + "additionalProperties": false, + "properties": { + "created_at": { + "type": "string" + }, + "duration_assertion": { + "anyOf": [ + { + "enum": [ + "PASS", + "TOO_FAST", + "TOO_SLOW" + ], + "type": "string" + }, + { + "type": "null" + } + ] + }, + "duration_ms": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "event": { + "enum": [ + "START", + "SUCCESS", + "FAILURE", + "LOG" + ], + "type": "string" + }, + "exit_code": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "id": { + "type": "string" + }, + "message": { + "type": [ + "string", + "null" + ] + }, + "payload": { + "type": [ + "string", + "null" + ] + }, + "payload_bytes": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "payload_truncated": { + "type": "boolean" + }, + "request_ip": { + "type": [ + "string", + "null" + ] + }, + "request_ua": { + "type": [ + "string", + "null" + ] + }, + "run_id": { + "type": [ + "string", + "null" + ] + }, + "started_at": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "id", + "run_id", + "event", + "exit_code", + "duration_ms", + "duration_assertion", + "message", + "payload", + "payload_truncated", + "payload_bytes", + "request_ip", + "request_ua", + "started_at", + "created_at" + ], + "type": "object" + }, + "type": "array" + }, + "pagination": { + "additionalProperties": false, + "properties": { + "has_next": { + "type": "boolean" + }, + "has_prev": { + "type": "boolean" + }, + "limit": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "page": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "total": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "total_pages": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + } + }, + "required": [ + "page", + "limit", + "total", + "total_pages", + "has_next", + "has_prev" + ], + "type": "object" + } + }, + "required": [ + "data", + "pagination" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "analyzed_period": { + "additionalProperties": false, + "properties": { + "from": { + "type": "string" + }, + "to": { + "type": "string" + }, + "total_pings": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + } + }, + "required": [ + "from", + "to", + "total_pings" + ], + "type": "object" + }, + "warnings": { + "items": { + "additionalProperties": false, + "properties": { + "affected_count": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "message": { + "type": "string" + }, + "recommendation": { + "type": "string" + }, + "type": { + "enum": [ + "MISSING_RUN_ID", + "MISSING_START" + ], + "type": "string" + } + }, + "required": [ + "type", + "message", + "affected_count", + "recommendation" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "warnings", + "analyzed_period" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "check_region": { + "type": "string" + }, + "check_status": { + "enum": [ + "ok", + "probe_error" + ], + "type": "string" + }, + "created_at": { + "type": "string" + }, + "cycle_id": { + "type": [ + "string", + "null" + ] + }, + "error": { + "type": [ + "string", + "null" + ] + }, + "id": { + "type": "string" + }, + "is_up": { + "type": "boolean" + }, + "monitor_id": { + "type": "string" + }, + "response_time_ms": { + "type": "number" + }, + "ssl_expires_at": { + "type": [ + "string", + "null" + ] + }, + "ssl_issuer": { + "type": [ + "string", + "null" + ] + }, + "status_code": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "id", + "monitor_id", + "status_code", + "response_time_ms", + "is_up", + "error", + "ssl_expires_at", + "ssl_issuer", + "check_region", + "check_status", + "created_at" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "avg_ms": { + "type": [ + "number", + "null" + ] + }, + "down_count": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "max_ms": { + "type": [ + "number", + "null" + ] + }, + "min_ms": { + "type": [ + "number", + "null" + ] + }, + "p95_ms": { + "type": [ + "number", + "null" + ] + }, + "total_checks": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "up_count": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "uptime_percentage": { + "type": "number" + } + }, + "required": [ + "avg_ms", + "min_ms", + "max_ms", + "p95_ms", + "total_checks", + "up_count", + "down_count", + "uptime_percentage" + ], + "type": "object" + } +]
- Changed
get_uptime_summary4 fields changed- removed
Output schema / properties / monitors / items / properties / avg_ms / anyOfRemoved value: -[ - { - "type": "number" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitors / items / properties / avg_ms / typeAdded value: +[ + "number", + "null" +] - removed
Output schema / properties / monitors / items / properties / p95_ms / anyOfRemoved value: -[ - { - "type": "number" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitors / items / properties / p95_ms / typeAdded value: +[ + "number", + "null" +]
- Changed
list_incidents16 fields changed- removed
Output schema / properties / incidents / items / properties / acknowledged_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / incidents / items / properties / acknowledged_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / incidents / items / properties / event / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / incidents / items / properties / event / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / incidents / items / properties / monitor_id / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / incidents / items / properties / monitor_id / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / incidents / items / properties / project_id / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / incidents / items / properties / project_id / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / incidents / items / properties / reopened_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / incidents / items / properties / reopened_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / incidents / items / properties / resolved_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / incidents / items / properties / resolved_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / incidents / items / properties / started_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / incidents / items / properties / started_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / incidents / items / properties / status / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / incidents / items / properties / status / typeAdded value: +[ + "string", + "null" +]
- Changed
list_monitors20 fields changed- removed
Output schema / properties / monitors / items / properties / alert_enabled / anyOfRemoved value: -[ - { - "type": "boolean" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitors / items / properties / alert_enabled / typeAdded value: +[ + "boolean", + "null" +] - removed
Output schema / properties / monitors / items / properties / created_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitors / items / properties / created_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitors / items / properties / description / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitors / items / properties / description / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitors / items / properties / last_success_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitors / items / properties / last_success_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitors / items / properties / next_expected_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitors / items / properties / next_expected_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitors / items / properties / project_id / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitors / items / properties / project_id / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitors / items / properties / slug / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitors / items / properties / slug / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitors / items / properties / status / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitors / items / properties / status / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitors / items / properties / timezone / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitors / items / properties / timezone / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitors / items / properties / type / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitors / items / properties / type / typeAdded value: +[ + "string", + "null" +]
- Changed
list_projects18 fields changed- removed
Output schema / properties / projects / items / properties / created_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / projects / items / properties / created_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / projects / items / properties / description / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / projects / items / properties / description / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / projects / items / properties / notification_channels / items / properties / enabled / anyOfRemoved value: -[ - { - "type": "boolean" - }, - { - "type": "null" - } -] - added
Output schema / properties / projects / items / properties / notification_channels / items / properties / enabled / typeAdded value: +[ + "boolean", + "null" +] - removed
Output schema / properties / projects / items / properties / notification_channels / items / properties / is_default / anyOfRemoved value: -[ - { - "type": "boolean" - }, - { - "type": "null" - } -] - added
Output schema / properties / projects / items / properties / notification_channels / items / properties / is_default / typeAdded value: +[ + "boolean", + "null" +] - removed
Output schema / properties / projects / items / properties / notification_channels / items / properties / name / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / projects / items / properties / notification_channels / items / properties / name / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / projects / items / properties / notification_channels / items / properties / type / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / projects / items / properties / notification_channels / items / properties / type / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / projects / items / properties / notification_groups / items / properties / description / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / projects / items / properties / notification_groups / items / properties / description / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / projects / items / properties / owner_email / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / projects / items / properties / owner_email / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / projects / items / properties / plan / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / projects / items / properties / plan / typeAdded value: +[ + "string", + "null" +]
- Changed
manage_incident16 fields changed- removed
Output schema / properties / incident / properties / acknowledged_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / incident / properties / acknowledged_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / incident / properties / event / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / incident / properties / event / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / incident / properties / monitor_id / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / incident / properties / monitor_id / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / incident / properties / project_id / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / incident / properties / project_id / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / incident / properties / reopened_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / incident / properties / reopened_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / incident / properties / resolved_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / incident / properties / resolved_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / incident / properties / started_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / incident / properties / started_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / incident / properties / status / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / incident / properties / status / typeAdded value: +[ + "string", + "null" +]
- Changed
pause_monitor20 fields changed- removed
Output schema / properties / monitor / properties / alert_enabled / anyOfRemoved value: -[ - { - "type": "boolean" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / alert_enabled / typeAdded value: +[ + "boolean", + "null" +] - removed
Output schema / properties / monitor / properties / created_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / created_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / description / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / description / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / last_success_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / last_success_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / next_expected_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / next_expected_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / project_id / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / project_id / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / slug / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / slug / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / status / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / status / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / timezone / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / timezone / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / type / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / type / typeAdded value: +[ + "string", + "null" +]
- Added
ping_failure - Added
ping_start - Added
ping_success - Changed
resume_monitor20 fields changed- removed
Output schema / properties / monitor / properties / alert_enabled / anyOfRemoved value: -[ - { - "type": "boolean" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / alert_enabled / typeAdded value: +[ + "boolean", + "null" +] - removed
Output schema / properties / monitor / properties / created_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / created_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / description / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / description / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / last_success_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / last_success_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / next_expected_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / next_expected_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / project_id / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / project_id / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / slug / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / slug / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / status / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / status / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / timezone / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / timezone / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / type / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / type / typeAdded value: +[ + "string", + "null" +]
- Changed
update_monitor20 fields changed- removed
Output schema / properties / monitor / properties / alert_enabled / anyOfRemoved value: -[ - { - "type": "boolean" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / alert_enabled / typeAdded value: +[ + "boolean", + "null" +] - removed
Output schema / properties / monitor / properties / created_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / created_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / description / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / description / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / last_success_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / last_success_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / next_expected_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / next_expected_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / project_id / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / project_id / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / slug / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / slug / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / status / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / status / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / timezone / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / timezone / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / monitor / properties / type / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / monitor / properties / type / typeAdded value: +[ + "string", + "null" +]
- Changed
update_project8 fields changed- removed
Output schema / properties / project / properties / created_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / project / properties / created_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / project / properties / description / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / project / properties / description / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / project / properties / owner_email / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / project / properties / owner_email / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / project / properties / plan / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / project / properties / plan / typeAdded value: +[ + "string", + "null" +]
3 tool updates
v0.4.1- Changed
create_monitor1 field changed- added
Input schema / properties / uptime_locationsAdded value: +{ + "description": "Check locations for this monitor (beta, all plans — each location consumes 1 beat per check cycle, so a 2-location monitor costs double the beats of a 1-location one). Must include \"eu-central\"; the API rejects an array missing it, and rejects \"us-east\" outright if multi-location checking is not enabled for this project. Defaults to [\"eu-central\"] (today's single-vantage behavior).", + "items": { + "enum": [ + "eu-central", + "us-east" + ], + "type": "string" + }, + "maxItems": 2, + "minItems": 1, + "type": "array" +}
- Changed
get_monitor_history1 field changed- changed
Output schema / properties / data / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "data": { - "items": { - "additionalProperties": false, - "properties": { - "created_at": { - "type": "string" - }, - "duration_assertion": { - "anyOf": [ - { - "enum": [ - "PASS", - "TOO_FAST", - "TOO_SLOW" - ], - "type": "string" - }, - { - "type": "null" - } - ] - }, - "duration_ms": { - "anyOf": [ - { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - { - "type": "null" - } - ] - }, - "event": { - "enum": [ - "START", - "SUCCESS", - "FAILURE", - "LOG" - ], - "type": "string" - }, - "exit_code": { - "anyOf": [ - { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - { - "type": "null" - } - ] - }, - "id": { - "type": "string" - }, - "message": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "payload": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "payload_bytes": { - "anyOf": [ - { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - { - "type": "null" - } - ] - }, - "payload_truncated": { - "type": "boolean" - }, - "request_ip": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "request_ua": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "run_id": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "started_at": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - } - }, - "required": [ - "id", - "run_id", - "event", - "exit_code", - "duration_ms", - "duration_assertion", - "message", - "payload", - "payload_truncated", - "payload_bytes", - "request_ip", - "request_ua", - "started_at", - "created_at" - ], - "type": "object" - }, - "type": "array" - }, - "pagination": { - "additionalProperties": false, - "properties": { - "has_next": { - "type": "boolean" - }, - "has_prev": { - "type": "boolean" - }, - "limit": { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - "page": { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - "total": { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - "total_pages": { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - } - }, - "required": [ - "page", - "limit", - "total", - "total_pages", - "has_next", - "has_prev" - ], - "type": "object" - } - }, - "required": [ - "data", - "pagination" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "analyzed_period": { - "additionalProperties": false, - "properties": { - "from": { - "type": "string" - }, - "to": { - "type": "string" - }, - "total_pings": { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - } - }, - "required": [ - "from", - "to", - "total_pings" - ], - "type": "object" - }, - "warnings": { - "items": { - "additionalProperties": false, - "properties": { - "affected_count": { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - "message": { - "type": "string" - }, - "recommendation": { - "type": "string" - }, - "type": { - "enum": [ - "MISSING_RUN_ID", - "MISSING_START" - ], - "type": "string" - } - }, - "required": [ - "type", - "message", - "affected_count", - "recommendation" - ], - "type": "object" - }, - "type": "array" - } - }, - "required": [ - "warnings", - "analyzed_period" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "check_region": { - "type": "string" - }, - "created_at": { - "type": "string" - }, - "error": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "id": { - "type": "string" - }, - "is_up": { - "type": "boolean" - }, - "monitor_id": { - "type": "string" - }, - "response_time_ms": { - "type": "number" - }, - "ssl_expires_at": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "ssl_issuer": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - }, - "status_code": { - "anyOf": [ - { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - { - "type": "null" - } - ] - } - }, - "required": [ - "id", - "monitor_id", - "status_code", - "response_time_ms", - "is_up", - "error", - "ssl_expires_at", - "ssl_issuer", - "check_region", - "created_at" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "avg_ms": { - "anyOf": [ - { - "type": "number" - }, - { - "type": "null" - } - ] - }, - "down_count": { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - "max_ms": { - "anyOf": [ - { - "type": "number" - }, - { - "type": "null" - } - ] - }, - "min_ms": { - "anyOf": [ - { - "type": "number" - }, - { - "type": "null" - } - ] - }, - "p95_ms": { - "anyOf": [ - { - "type": "number" - }, - { - "type": "null" - } - ] - }, - "total_checks": { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - "up_count": { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - "uptime_percentage": { - "type": "number" - } - }, - "required": [ - "avg_ms", - "min_ms", - "max_ms", - "p95_ms", - "total_checks", - "up_count", - "down_count", - "uptime_percentage" - ], - "type": "object" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "data": { + "items": { + "additionalProperties": false, + "properties": { + "created_at": { + "type": "string" + }, + "duration_assertion": { + "anyOf": [ + { + "enum": [ + "PASS", + "TOO_FAST", + "TOO_SLOW" + ], + "type": "string" + }, + { + "type": "null" + } + ] + }, + "duration_ms": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "event": { + "enum": [ + "START", + "SUCCESS", + "FAILURE", + "LOG" + ], + "type": "string" + }, + "exit_code": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "id": { + "type": "string" + }, + "message": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "payload": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "payload_bytes": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "payload_truncated": { + "type": "boolean" + }, + "request_ip": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "request_ua": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "run_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "started_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "id", + "run_id", + "event", + "exit_code", + "duration_ms", + "duration_assertion", + "message", + "payload", + "payload_truncated", + "payload_bytes", + "request_ip", + "request_ua", + "started_at", + "created_at" + ], + "type": "object" + }, + "type": "array" + }, + "pagination": { + "additionalProperties": false, + "properties": { + "has_next": { + "type": "boolean" + }, + "has_prev": { + "type": "boolean" + }, + "limit": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "page": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "total": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "total_pages": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + } + }, + "required": [ + "page", + "limit", + "total", + "total_pages", + "has_next", + "has_prev" + ], + "type": "object" + } + }, + "required": [ + "data", + "pagination" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "analyzed_period": { + "additionalProperties": false, + "properties": { + "from": { + "type": "string" + }, + "to": { + "type": "string" + }, + "total_pings": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + } + }, + "required": [ + "from", + "to", + "total_pings" + ], + "type": "object" + }, + "warnings": { + "items": { + "additionalProperties": false, + "properties": { + "affected_count": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "message": { + "type": "string" + }, + "recommendation": { + "type": "string" + }, + "type": { + "enum": [ + "MISSING_RUN_ID", + "MISSING_START" + ], + "type": "string" + } + }, + "required": [ + "type", + "message", + "affected_count", + "recommendation" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "warnings", + "analyzed_period" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "check_region": { + "type": "string" + }, + "check_status": { + "enum": [ + "ok", + "probe_error" + ], + "type": "string" + }, + "created_at": { + "type": "string" + }, + "cycle_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "error": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "id": { + "type": "string" + }, + "is_up": { + "type": "boolean" + }, + "monitor_id": { + "type": "string" + }, + "response_time_ms": { + "type": "number" + }, + "ssl_expires_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "ssl_issuer": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "status_code": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "id", + "monitor_id", + "status_code", + "response_time_ms", + "is_up", + "error", + "ssl_expires_at", + "ssl_issuer", + "check_region", + "check_status", + "created_at" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "avg_ms": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "down_count": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "max_ms": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "min_ms": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "p95_ms": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "total_checks": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "up_count": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "uptime_percentage": { + "type": "number" + } + }, + "required": [ + "avg_ms", + "min_ms", + "max_ms", + "p95_ms", + "total_checks", + "up_count", + "down_count", + "uptime_percentage" + ], + "type": "object" + } +]
- Changed
update_monitor1 field changed- added
Input schema / properties / uptime_locationsAdded value: +{ + "description": "New check locations (UPTIME_HTTP only, beta). Fully replaces the existing list. Must include \"eu-central\"; each location consumes 1 beat per check cycle. The API rejects \"us-east\" if multi-location checking is not enabled for this project.", + "items": { + "enum": [ + "eu-central", + "us-east" + ], + "type": "string" + }, + "maxItems": 2, + "minItems": 1, + "type": "array" +}
16 tool updates
v0.3.0- Changed
check_dns1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "all_failed": { + "type": "boolean" + }, + "check_region": { + "type": "string" + }, + "checked_at": { + "type": "string" + }, + "hostname_checked": { + "type": "string" + }, + "ok": { + "const": true, + "type": "boolean" + }, + "records": { + "additionalProperties": false, + "properties": { + "A": { + "items": { + "type": "string" + }, + "type": "array" + }, + "AAAA": { + "items": { + "type": "string" + }, + "type": "array" + }, + "CNAME": { + "items": { + "type": "string" + }, + "type": "array" + }, + "MX": { + "items": { + "additionalProperties": false, + "properties": { + "exchange": { + "type": "string" + }, + "priority": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + } + }, + "required": [ + "exchange", + "priority" + ], + "type": "object" + }, + "type": "array" + }, + "NS": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "A", + "AAAA", + "CNAME", + "MX", + "NS" + ], + "type": "object" + }, + "resolution_errors": { + "additionalProperties": false, + "properties": { + "A": { + "type": "string" + }, + "AAAA": { + "type": "string" + }, + "CNAME": { + "type": "string" + }, + "MX": { + "type": "string" + }, + "NS": { + "type": "string" + } + }, + "type": "object" + } + }, + "required": [ + "ok", + "hostname_checked", + "records", + "resolution_errors", + "all_failed", + "checked_at", + "check_region" + ], + "type": "object" +}
- Changed
check_http1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "check_region": { + "type": "string" + }, + "checked_at": { + "type": "string" + }, + "error": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "final_url": { + "type": "string" + }, + "method_used": { + "enum": [ + "GET", + "HEAD" + ], + "type": "string" + }, + "ok": { + "const": true, + "type": "boolean" + }, + "redirect_chain": { + "items": { + "type": "string" + }, + "type": "array" + }, + "response_time_ms": { + "type": "number" + }, + "status": { + "enum": [ + "up", + "down" + ], + "type": "string" + }, + "status_code": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "timing": { + "additionalProperties": false, + "properties": { + "connect_ms": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "dns_ms": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "download_ms": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "tls_ms": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "ttfb_ms": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "dns_ms", + "connect_ms", + "tls_ms", + "ttfb_ms", + "download_ms" + ], + "type": "object" + }, + "tls_error": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "ok", + "status", + "status_code", + "method_used", + "response_time_ms", + "timing", + "final_url", + "redirect_chain", + "tls_error", + "error", + "checked_at", + "check_region" + ], + "type": "object" +}
- Changed
check_ssl1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "chain_valid": { + "type": "boolean" + }, + "check_region": { + "type": "string" + }, + "checked_at": { + "type": "string" + }, + "days_remaining": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "error": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "expires_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "hostname_checked": { + "type": "string" + }, + "hostname_match": { + "type": "boolean" + }, + "issuer": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "ok": { + "const": true, + "type": "boolean" + }, + "port_checked": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "sans": { + "items": { + "type": "string" + }, + "type": "array" + }, + "self_signed": { + "type": "boolean" + }, + "signature_algorithm": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "subject": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "valid": { + "type": "boolean" + }, + "valid_from": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "ok", + "valid", + "issuer", + "subject", + "sans", + "expires_at", + "valid_from", + "days_remaining", + "chain_valid", + "self_signed", + "hostname_match", + "signature_algorithm", + "error", + "hostname_checked", + "port_checked", + "checked_at", + "check_region" + ], + "type": "object" +}
- Changed
create_monitor33 fields changed- added
Input schema / properties / alert_enabled / descriptionAdded value: +"Whether this monitor sends alert notifications at all. Incidents are always recorded regardless. Defaults to true." - added
Input schema / properties / alert_surge_threshold / descriptionAdded value: +"After this many consecutive alert notifications for this monitor, Drumbeats auto-pauses further notifications for 1 hour (surge protection). Incidents are still recorded either way — this only gates whether a notification is sent. Defaults to 10." - added
Input schema / properties / description / anyOfAdded value: +[ + { + "maxLength": 500, + "type": "string" + }, + { + "type": "null" + } +] - added
Input schema / properties / description / descriptionAdded value: +"Optional human-readable description of what this monitor checks, shown in the dashboard and in alert notifications." - removed
Input schema / properties / description / maxLengthRemoved value: -500 - removed
Input schema / properties / description / typeRemoved value: -"string" - added
Input schema / properties / failure_tolerance / descriptionAdded value: +"Number of consecutive FAILURE pings (or non-zero exit codes) that transitions the monitor to DOWN and opens a FAILED incident. 1 = alert on the very first failure; 3 = allow 2 failures before alerting. Applies to every monitor type, including JOB_BASIC. Defaults to 1." - added
Input schema / properties / grace_period_seconds / descriptionAdded value: +"Seconds to wait after the expected check-in time before counting a miss (must be at least 15 — a lower value can trap a monitor in DOWN, since a ping arriving even slightly late would never count as on-time). Doesn't apply to JOB_BASIC (event-driven, no schedule to be late against). Defaults to 300 (5 minutes)." - changed
Input schema / properties / grace_period_seconds / minimumPrevious value: -0New value: +15 - added
Input schema / properties / max_duration_seconds / descriptionAdded value: +"If set, a job (not UPTIME_HTTP) that reports a longer duration than this many seconds creates a DURATION_HIGH incident — informational only, does not affect UP/DOWN status. Must be greater than min_duration_seconds if both are set. For JOB_BASIC specifically this also acts as a hard timeout: a run that started (a START ping) but never finished within this many seconds is automatically marked FAILED." - added
Input schema / properties / min_duration_seconds / descriptionAdded value: +"If set, a job (not UPTIME_HTTP) that reports a shorter duration than this many seconds creates a DURATION_LOW incident — informational only, does not affect UP/DOWN status. Must be less than max_duration_seconds if both are set." - added
Input schema / properties / name / descriptionAdded value: +"Display name for the monitor, shown in the dashboard and in alert notifications." - added
Input schema / properties / notification_channel_ids / descriptionAdded value: +"Individual notification channel ids to alert directly, in addition to notification_group_ids (ids from list_projects include=channels)." - added
Input schema / properties / notification_group_ids / descriptionAdded value: +"Notification group ids to alert on incidents (ids from list_projects include=groups). Omitted or empty uses the project's default notification group." - added
Input schema / properties / project_id / descriptionAdded value: +"The project this monitor belongs to (id from list_projects)." - added
Input schema / properties / retention_count / descriptionAdded value: +"Number of most-recent pings (or uptime check results) to retain for this monitor; older ones are pruned. Range 10-1000, defaults to 200." - added
Input schema / properties / schedule / descriptionAdded value: +"Schedule expression; format depends on type. JOB_CRON: a cron expression (e.g. \"0 2 * * *\"). JOB_HEARTBEAT and UPTIME_HTTP: an interval string \"<number><unit>\" with unit s/m/h/d/w (e.g. \"5m\", \"1h\") — for JOB_HEARTBEAT this is how often your job must ping in, for UPTIME_HTTP this is the poll interval. JOB_BASIC: required but ignored for timing (JOB_BASIC is event-driven and never goes overdue on a schedule) — pass any non-empty placeholder such as \"@event\"." - added
Input schema / properties / schedule_tolerance / descriptionAdded value: +"Number of consecutive missed check-ins that transitions the monitor to DOWN and opens a MISSED incident. 1 = alert on the very first miss; 3 = allow 2 misses before alerting. Doesn't apply to JOB_BASIC. Defaults to 1." - added
Input schema / properties / slug / descriptionAdded value: +"Optional URL-safe identifier, unique within the project (lowercase letters, numbers, hyphens; max 50 chars). Not auto-generated from name — omit to leave unset. Lets you reference the monitor by a stable slug instead of its id." - added
Input schema / properties / tags / descriptionAdded value: +"Freeform labels for filtering and grouping monitors in the dashboard (max 10 tags, 50 chars each)." - added
Input schema / properties / timezone / descriptionAdded value: +"IANA timezone (e.g. \"UTC\", \"America/New_York\") used to interpret the schedule. Only affects JOB_CRON (cron-tick calculation) — interval-based types (JOB_BASIC, JOB_HEARTBEAT, UPTIME_HTTP) ignore it. Defaults to UTC." - added
Input schema / properties / type / descriptionAdded value: +"Monitor type — determines how \"schedule\" is interpreted and what triggers a DOWN transition. JOB_CRON: cron schedule. JOB_BASIC: event-driven, no schedule expectation. JOB_HEARTBEAT: passive endpoint your job pings on an interval. UPTIME_HTTP: Drumbeats polls uptime_url on an interval. See the tool description for details on each." - added
Input schema / properties / uptime_expected_status / descriptionAdded value: +"HTTP status codes considered \"up\" (e.g. [200, 201]). Omit or leave empty to use the default: any 2xx response is up." - added
Input schema / properties / uptime_follow_redirects / descriptionAdded value: +"Whether to follow HTTP redirects (up to 10 hops; an https→http downgrade redirect is always refused). Defaults to true." - added
Input schema / properties / uptime_headers / descriptionAdded value: +"Custom request headers to send (e.g. an API key). Sent on the initial request and on same-origin redirect hops only — stripped on cross-origin redirects so credentials don't leak. Hop-by-hop and connection-control headers (Host, Content-Length, Connection, Transfer-Encoding, etc.) are rejected by the API." - added
Input schema / properties / uptime_keyword / descriptionAdded value: +"Substring to search for in the response body (max 1024 chars). If set (and uptime_keyword_absent is false), the check fails when the keyword is missing from an otherwise-successful response." - added
Input schema / properties / uptime_keyword_absent / descriptionAdded value: +"Flips uptime_keyword's check: when true, the check fails if the keyword IS found. Defaults to false (keyword must be present)." - added
Input schema / properties / uptime_method / descriptionAdded value: +"HTTP method for the check. HEAD is lighter-weight; POST allows sending uptime_request_body. Defaults to GET." - added
Input schema / properties / uptime_request_body / descriptionAdded value: +"Request body to send when uptime_method is POST (max 10000 chars). Ignored for GET/HEAD." - added
Input schema / properties / uptime_timeout_ms / descriptionAdded value: +"Per-check timeout in milliseconds (1000-30000). Defaults to 10000." - added
Input schema / properties / uptime_url / descriptionAdded value: +"The URL Drumbeats polls on the schedule interval. Required when type is UPTIME_HTTP, rejected for job types. Must be http(s) and must not embed credentials (user:pass@host) — put auth in uptime_headers instead." - added
Input schema / properties / uptime_verify_ssl / descriptionAdded value: +"Whether to reject invalid or self-signed TLS certificates during the check. Set false to allow checking a host with a known-bad cert. Defaults to true." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "monitor": { + "additionalProperties": false, + "properties": { + "alert_enabled": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ] + }, + "consecutive_failures": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "created_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "description": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "grace_period_seconds": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "id": { + "type": "string" + }, + "last_success_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "type": "string" + }, + "next_expected_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "project_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "slug": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "status": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "timezone": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "total_pings_received": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "type": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "id", + "name", + "type", + "status", + "slug", + "project_id", + "description", + "tags", + "timezone", + "grace_period_seconds", + "alert_enabled", + "total_pings_received", + "consecutive_failures", + "last_success_at", + "next_expected_at", + "created_at" + ], + "type": "object" + } + }, + "required": [ + "monitor" + ], + "type": "object" +}
- Changed
create_project1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "project": { + "additionalProperties": false, + "properties": { + "created_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "description": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "id": { + "type": "string" + }, + "member_count": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "name": { + "type": "string" + }, + "owner_email": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "plan": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "id", + "name", + "description", + "plan", + "created_at", + "member_count", + "owner_email" + ], + "type": "object" + } + }, + "required": [ + "project" + ], + "type": "object" +}
- Changed
get_monitor1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "monitor": { + "additionalProperties": false, + "properties": { + "alert_enabled": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ] + }, + "consecutive_failures": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "created_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "description": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "grace_period_seconds": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "id": { + "type": "string" + }, + "last_success_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "type": "string" + }, + "next_expected_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "project_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "slug": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "status": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "timezone": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "total_pings_received": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "type": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "id", + "name", + "type", + "status", + "slug", + "project_id", + "description", + "tags", + "timezone", + "grace_period_seconds", + "alert_enabled", + "total_pings_received", + "consecutive_failures", + "last_success_at", + "next_expected_at", + "created_at" + ], + "type": "object" + } + }, + "required": [ + "monitor" + ], + "type": "object" +}
- Changed
get_monitor_history1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "data": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "data": { + "items": { + "additionalProperties": false, + "properties": { + "created_at": { + "type": "string" + }, + "duration_assertion": { + "anyOf": [ + { + "enum": [ + "PASS", + "TOO_FAST", + "TOO_SLOW" + ], + "type": "string" + }, + { + "type": "null" + } + ] + }, + "duration_ms": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "event": { + "enum": [ + "START", + "SUCCESS", + "FAILURE", + "LOG" + ], + "type": "string" + }, + "exit_code": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "id": { + "type": "string" + }, + "message": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "payload": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "payload_bytes": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "payload_truncated": { + "type": "boolean" + }, + "request_ip": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "request_ua": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "run_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "started_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "id", + "run_id", + "event", + "exit_code", + "duration_ms", + "duration_assertion", + "message", + "payload", + "payload_truncated", + "payload_bytes", + "request_ip", + "request_ua", + "started_at", + "created_at" + ], + "type": "object" + }, + "type": "array" + }, + "pagination": { + "additionalProperties": false, + "properties": { + "has_next": { + "type": "boolean" + }, + "has_prev": { + "type": "boolean" + }, + "limit": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "page": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "total": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "total_pages": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + } + }, + "required": [ + "page", + "limit", + "total", + "total_pages", + "has_next", + "has_prev" + ], + "type": "object" + } + }, + "required": [ + "data", + "pagination" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "analyzed_period": { + "additionalProperties": false, + "properties": { + "from": { + "type": "string" + }, + "to": { + "type": "string" + }, + "total_pings": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + } + }, + "required": [ + "from", + "to", + "total_pings" + ], + "type": "object" + }, + "warnings": { + "items": { + "additionalProperties": false, + "properties": { + "affected_count": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "message": { + "type": "string" + }, + "recommendation": { + "type": "string" + }, + "type": { + "enum": [ + "MISSING_RUN_ID", + "MISSING_START" + ], + "type": "string" + } + }, + "required": [ + "type", + "message", + "affected_count", + "recommendation" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "warnings", + "analyzed_period" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "check_region": { + "type": "string" + }, + "created_at": { + "type": "string" + }, + "error": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "id": { + "type": "string" + }, + "is_up": { + "type": "boolean" + }, + "monitor_id": { + "type": "string" + }, + "response_time_ms": { + "type": "number" + }, + "ssl_expires_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "ssl_issuer": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "status_code": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "id", + "monitor_id", + "status_code", + "response_time_ms", + "is_up", + "error", + "ssl_expires_at", + "ssl_issuer", + "check_region", + "created_at" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "avg_ms": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "down_count": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "max_ms": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "min_ms": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "p95_ms": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "total_checks": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "up_count": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "uptime_percentage": { + "type": "number" + } + }, + "required": [ + "avg_ms", + "min_ms", + "max_ms", + "p95_ms", + "total_checks", + "up_count", + "down_count", + "uptime_percentage" + ], + "type": "object" + } + ] + }, + "kind": { + "enum": [ + "pings", + "warnings", + "checks", + "response_times" + ], + "type": "string" + }, + "monitor_id": { + "type": "string" + } + }, + "required": [ + "monitor_id", + "kind", + "data" + ], + "type": "object" +}
- Changed
get_uptime_summary1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "monitors": { + "items": { + "additionalProperties": false, + "properties": { + "avg_ms": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "down_count": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "monitor_id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "p95_ms": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "total_checks": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "up_count": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "uptime_percentage": { + "type": "number" + } + }, + "type": "object" + }, + "type": "array" + }, + "overall": { + "additionalProperties": false, + "properties": { + "down_count": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "total_checks": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "up_count": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "uptime_percentage": { + "type": "number" + } + }, + "type": "object" + }, + "period_hours": { + "type": "number" + } + }, + "type": "object" +}
- Changed
list_incidents1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "incidents": { + "items": { + "additionalProperties": false, + "properties": { + "acknowledged_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "event": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "id": { + "type": "string" + }, + "monitor_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "project_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "reopened_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "resolved_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "started_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "status": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "id", + "monitor_id", + "project_id", + "event", + "status", + "started_at", + "acknowledged_at", + "resolved_at", + "reopened_at" + ], + "type": "object" + }, + "type": "array" + }, + "pagination": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "has_next": { + "type": "boolean" + }, + "has_prev": { + "type": "boolean" + }, + "limit": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "page": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "total": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "total_pages": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + } + }, + "required": [ + "page", + "limit", + "total", + "total_pages", + "has_next", + "has_prev" + ], + "type": "object" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "incidents", + "pagination" + ], + "type": "object" +}
- Changed
list_monitors1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "monitors": { + "items": { + "additionalProperties": false, + "properties": { + "alert_enabled": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ] + }, + "consecutive_failures": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "created_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "description": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "grace_period_seconds": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "id": { + "type": "string" + }, + "last_success_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "type": "string" + }, + "next_expected_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "project_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "slug": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "status": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "timezone": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "total_pings_received": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "type": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "id", + "name", + "type", + "status", + "slug", + "project_id", + "description", + "tags", + "timezone", + "grace_period_seconds", + "alert_enabled", + "total_pings_received", + "consecutive_failures", + "last_success_at", + "next_expected_at", + "created_at" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "monitors" + ], + "type": "object" +}
- Changed
list_projects1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "projects": { + "items": { + "additionalProperties": false, + "properties": { + "created_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "description": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "id": { + "type": "string" + }, + "member_count": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "name": { + "type": "string" + }, + "notification_channels": { + "items": { + "additionalProperties": false, + "properties": { + "enabled": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ] + }, + "id": { + "type": "string" + }, + "is_default": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ] + }, + "name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "type": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "id", + "name", + "type", + "enabled", + "is_default" + ], + "type": "object" + }, + "type": "array" + }, + "notification_groups": { + "items": { + "additionalProperties": false, + "properties": { + "description": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "id": { + "type": "string" + }, + "name": { + "type": "string" + } + }, + "required": [ + "id", + "name", + "description" + ], + "type": "object" + }, + "type": "array" + }, + "owner_email": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "plan": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "id", + "name", + "description", + "plan", + "created_at", + "member_count", + "owner_email" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "projects" + ], + "type": "object" +}
- Changed
manage_incident1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "action": { + "enum": [ + "get", + "acknowledge", + "resolve" + ], + "type": "string" + }, + "incident": { + "additionalProperties": false, + "properties": { + "acknowledged_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "event": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "id": { + "type": "string" + }, + "monitor_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "project_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "reopened_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "resolved_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "started_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "status": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "id", + "monitor_id", + "project_id", + "event", + "status", + "started_at", + "acknowledged_at", + "resolved_at", + "reopened_at" + ], + "type": "object" + } + }, + "required": [ + "action", + "incident" + ], + "type": "object" +}
- Changed
pause_monitor1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "monitor": { + "additionalProperties": false, + "properties": { + "alert_enabled": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ] + }, + "consecutive_failures": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "created_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "description": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "grace_period_seconds": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "id": { + "type": "string" + }, + "last_success_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "type": "string" + }, + "next_expected_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "project_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "slug": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "status": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "timezone": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "total_pings_received": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "type": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "id", + "name", + "type", + "status", + "slug", + "project_id", + "description", + "tags", + "timezone", + "grace_period_seconds", + "alert_enabled", + "total_pings_received", + "consecutive_failures", + "last_success_at", + "next_expected_at", + "created_at" + ], + "type": "object" + } + }, + "required": [ + "monitor" + ], + "type": "object" +}
- Changed
resume_monitor1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "monitor": { + "additionalProperties": false, + "properties": { + "alert_enabled": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ] + }, + "consecutive_failures": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "created_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "description": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "grace_period_seconds": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "id": { + "type": "string" + }, + "last_success_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "type": "string" + }, + "next_expected_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "project_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "slug": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "status": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "timezone": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "total_pings_received": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "type": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "id", + "name", + "type", + "status", + "slug", + "project_id", + "description", + "tags", + "timezone", + "grace_period_seconds", + "alert_enabled", + "total_pings_received", + "consecutive_failures", + "last_success_at", + "next_expected_at", + "created_at" + ], + "type": "object" + } + }, + "required": [ + "monitor" + ], + "type": "object" +}
- Changed
update_monitor34 fields changed- added
Input schema / properties / alert_enabled / descriptionAdded value: +"Whether this monitor sends alert notifications at all." - added
Input schema / properties / alert_surge_threshold / descriptionAdded value: +"After this many consecutive alert notifications, Drumbeats auto-pauses further notifications for 1 hour (incidents keep recording regardless)." - added
Input schema / properties / description / descriptionAdded value: +"New description (max 500 chars). Pass null to clear." - added
Input schema / properties / failure_tolerance / descriptionAdded value: +"Number of consecutive FAILURE pings before transitioning to DOWN (1 = alert on the very first failure). Applies to every monitor type, including JOB_BASIC." - added
Input schema / properties / grace_period_seconds / descriptionAdded value: +"Seconds to wait after the expected check-in time before counting a miss (must be at least 15). Ignored for JOB_BASIC." - changed
Input schema / properties / grace_period_seconds / minimumPrevious value: -0New value: +15 - added
Input schema / properties / max_duration_seconds / descriptionAdded value: +"If set, a job (not UPTIME_HTTP) reporting a longer duration than this creates a DURATION_HIGH incident (informational only). Must be greater than min_duration_seconds if both are set. For JOB_BASIC this also acts as a hard timeout on started-but-unfinished runs. Pass null to clear." - added
Input schema / properties / min_duration_seconds / descriptionAdded value: +"If set, a job (not UPTIME_HTTP) reporting a shorter duration than this creates a DURATION_LOW incident (informational only). Must be less than max_duration_seconds if both are set. Pass null to clear." - added
Input schema / properties / name / descriptionAdded value: +"New display name for the monitor." - added
Input schema / properties / notification_channel_ids / descriptionAdded value: +"Individual notification channel ids to alert directly (ids from list_projects include=channels). Fully replaces the existing list, not merged." - added
Input schema / properties / notification_group_ids / descriptionAdded value: +"Notification group ids to alert on incidents (ids from list_projects include=groups). Fully replaces the existing list, not merged — omitted or empty falls back to the project's default group." - added
Input schema / properties / retention_count / descriptionAdded value: +"Number of most-recent pings/check-results to retain (10-1000); older ones are pruned." - added
Input schema / properties / schedule / descriptionAdded value: +"New schedule expression; format depends on the (possibly also-updated) type — see create_monitor's schedule field for the per-type format. Changing it recalculates next_expected_at and resets the schedule anchor for JOB_HEARTBEAT/UPTIME_HTTP." - added
Input schema / properties / schedule_tolerance / descriptionAdded value: +"Number of consecutive missed check-ins before transitioning to DOWN (1 = alert on the very first miss). Ignored for JOB_BASIC." - added
Input schema / properties / slug / anyOfAdded value: +[ + { + "maxLength": 50, + "pattern": "^[a-z0-9-]+$", + "type": "string" + }, + { + "type": "null" + } +] - added
Input schema / properties / slug / descriptionAdded value: +"New URL-safe identifier, unique within the project (lowercase letters, numbers, hyphens; max 50 chars). Pass null to clear." - removed
Input schema / properties / slug / maxLengthRemoved value: -50 - removed
Input schema / properties / slug / patternRemoved value: -"^[a-z0-9-]+$" - removed
Input schema / properties / slug / typeRemoved value: -"string" - added
Input schema / properties / status / descriptionAdded value: +"Manually set status. UP forces recovery — resets consecutive_failures, consecutive_misses, and consecutive_alerts to 0, even if the monitor has not actually recovered. PAUSED stops checks/alerts without resetting counters. For the common pause/resume flow, prefer pause_monitor / resume_monitor." - added
Input schema / properties / tags / descriptionAdded value: +"New tag list (max 10 tags, 50 chars each). Fully replaces the existing tags, not merged — include every tag you want kept." - added
Input schema / properties / timezone / descriptionAdded value: +"New IANA timezone (e.g. \"UTC\", \"America/New_York\"). Only affects JOB_CRON schedule interpretation." - added
Input schema / properties / type / descriptionAdded value: +"Change the monitor's type. Switching type recalculates the schedule (next_expected_at) and gates which fields apply — uptime_* fields become required/rejected based on the resulting type. Rarely changed after creation." - added
Input schema / properties / uptime_expected_status / descriptionAdded value: +"HTTP status codes considered \"up\" (UPTIME_HTTP only). Empty means the default: any 2xx response is up." - added
Input schema / properties / uptime_follow_redirects / descriptionAdded value: +"Whether to follow HTTP redirects, up to 10 hops (UPTIME_HTTP only)." - added
Input schema / properties / uptime_headers / descriptionAdded value: +"Custom request headers (UPTIME_HTTP only). Stripped on cross-origin redirects; hop-by-hop/connection headers are rejected by the API. Pass null to clear." - added
Input schema / properties / uptime_keyword / descriptionAdded value: +"Substring to search for in the response body (UPTIME_HTTP only, max 1024 chars). Pass null to clear." - added
Input schema / properties / uptime_keyword_absent / descriptionAdded value: +"Flips uptime_keyword's check: true means the check fails if the keyword IS found (UPTIME_HTTP only)." - added
Input schema / properties / uptime_method / descriptionAdded value: +"HTTP method for the check (UPTIME_HTTP only). HEAD is lighter-weight; POST allows uptime_request_body." - added
Input schema / properties / uptime_request_body / descriptionAdded value: +"Request body sent when uptime_method is POST (UPTIME_HTTP only, max 10000 chars). Pass null to clear." - added
Input schema / properties / uptime_timeout_ms / descriptionAdded value: +"Per-check timeout in milliseconds, 1000-30000 (UPTIME_HTTP only)." - added
Input schema / properties / uptime_url / descriptionAdded value: +"New URL to poll. Only allowed when the monitor's type is (or is being changed to) UPTIME_HTTP. Must be http(s) and must not embed credentials (user:pass@host) — put auth in uptime_headers instead." - added
Input schema / properties / uptime_verify_ssl / descriptionAdded value: +"Whether to reject invalid/self-signed TLS certificates during the check (UPTIME_HTTP only)." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "monitor": { + "additionalProperties": false, + "properties": { + "alert_enabled": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ] + }, + "consecutive_failures": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "created_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "description": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "grace_period_seconds": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "id": { + "type": "string" + }, + "last_success_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "type": "string" + }, + "next_expected_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "project_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "slug": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "status": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "timezone": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "total_pings_received": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "type": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "id", + "name", + "type", + "status", + "slug", + "project_id", + "description", + "tags", + "timezone", + "grace_period_seconds", + "alert_enabled", + "total_pings_received", + "consecutive_failures", + "last_success_at", + "next_expected_at", + "created_at" + ], + "type": "object" + } + }, + "required": [ + "monitor" + ], + "type": "object" +}
- Changed
update_project1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "project": { + "additionalProperties": false, + "properties": { + "created_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "description": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "id": { + "type": "string" + }, + "member_count": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "name": { + "type": "string" + }, + "owner_email": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "plan": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "id", + "name", + "description", + "plan", + "created_at", + "member_count", + "owner_email" + ], + "type": "object" + } + }, + "required": [ + "project" + ], + "type": "object" +}
16 tool updates
v0.1.1- Added
check_dns - Added
check_http - Added
check_ssl - Added
create_monitor - Added
create_project - Added
get_monitor - Added
get_monitor_history - Added
get_uptime_summary - Added
list_incidents - Added
list_monitors - Added
list_projects - Added
manage_incident - Added
pause_monitor - Added
resume_monitor - Added
update_monitor - Added
update_project
TDQS
Scored across 19 tools
Each tool targets a distinct resource or action, and the multi-action tools (get_monitor_history with kind, manage_incident with action, create_monitor with type) are explicitly documented so boundaries are clear. The only mild overlap is update_monitor's status field versus pause_monitor/resume_monitor, which the descriptions acknowledge and cross-reference.
Names follow a uniform snake_case verb_noun pattern (list_projects, create_monitor, get_monitor_history, pause_monitor, check_ssl), with consistent prefixes for grouped operations. No mixed casing or stylistic drift across the 19 tools.
Nineteen tools is on the heavier side but each maps to a real operation across projects, monitors, incidents, pings, and stateless diagnostics. Nothing feels redundant or padded, though a few operations (pause/resume, three check_* tools) could arguably be consolidated.
Core lifecycle is covered: project and monitor create/read/update/pause plus incident listing and triage, and pings for jobs. However, there are no delete operations for projects or monitors, and no tools to create/update notification channels or groups even though alert wiring depends on their ids — an agent must go outside the server for that.
Maintenance
Related MCP Connectors
MCP server for Uptrack uptime monitoring. Manage monitors and incidents from AI agents.
AI-powered incident management and server monitoring via MCP.
Uptime, SSL, DNS and domain monitoring you can talk to from Claude or any MCP client.
Read-only MCP server for AIStatusDashboard status, incidents, metrics, and fallback recommendations.
Related MCP Servers
- AlicenseAqualityCmaintenanceMCP server for CronAlert uptime monitoring — manage monitors, check results, and incidents from any MCP-compatible AI client.9102 npmMIT

uptrack-mcpofficial
AlicenseNot gradedqualityBmaintenanceMCP server for Uptrack uptime monitoring. Manage monitors and incidents from AI agents like Claude, ChatGPT, and Cursor.16 npmMIT- AlicenseBqualityDmaintenanceMCP server for Loggy that enables AI coding assistants to manage heartbeats, status pages, uptime monitors, feature flags, and logs via natural language.15MIT
- AlicenseAqualityDmaintenanceAn MCP server that exposes live network monitoring data as Resources and diagnostic capabilities as Tools, letting AI assistants query network health conversationally.6MIT