A
licenseA
qualityC
maintenanceMCP server for CronAlert uptime monitoring — manage monitors, check results, and incidents from any MCP-compatible AI client.
9
59 npm
MIT
Drumbeats MCP
Officialby drumbeats-io
Drumbeats MCP is an MCP server that lets you manage uptime and heartbeat monitoring, triage incidents, and run on-demand diagnostics from any MCP-capable AI client (Claude, Cursor, VS Code, etc.).
Projects & Monitors
List/create/update projects — view all projects accessible via your API key, create new ones, or rename/update descriptions
Create monitors — set up cron job (
JOB_CRON), event-driven (JOB_BASIC), heartbeat (JOB_HEARTBEAT), or HTTP uptime (UPTIME_HTTP) monitors with alert channels/groupsList/get/update monitors — view all monitors in a project, fetch full config for a single monitor, or partially update settings
Pause/resume monitors — stop or restart checks and alert notifications
Observability & Incident Triage
Monitor history — retrieve recent pings, warnings, uptime check results, and response time stats
Uptime summary — get a project-wide SLA/uptime rollup across all uptime monitors for a given time window
List & manage incidents — browse downtime and missed-run incidents (filterable by status: OPEN, ACKNOWLEDGED, RESOLVED), then get details, acknowledge, or resolve them
Diagnostics (no account required)
HTTP check — verify reachability, status code, response time, and redirect chain for any HTTP(S) URL
SSL check — inspect a host's TLS/SSL certificate for validity, expiry date, issuer, and chain status
DNS check — resolve a hostname to its A, AAAA, CNAME, MX, and NS records
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 MCP
The official Model Context Protocol server for Drumbeats — run your monitoring from any AI client. Create monitors, triage incidents, and run HTTP / SSL / DNS checks in plain language from Claude, Cursor, VS Code, or any MCP-capable tool.
What is Drumbeats?
Drumbeats is heartbeat and uptime monitoring for background jobs and services — cron jobs, queues, scheduled tasks, and HTTP endpoints. If a job stops checking in or a site goes down, Drumbeats alerts you. Create a free account at drumbeats.io.
Related MCP server: uptrack-mcp
Install
Add the server to your AI client and set one environment variable — your Drumbeats account API key:
{
"mcpServers": {
"drumbeats": {
"command": "npx",
"args": ["-y", "@drumbeats/mcp"],
"env": { "DRUMBEATS_API_KEY": "dk_your_key" }
}
}
}Get a key — at drumbeats.io → Account → API keys. An account-scoped key (
dk_…) works across every project you own or belong to.Add the config — paste the block above into your client's MCP config and restart it.
Ask — "List my monitors."
Claude Desktop: prefer a one-click install — download the latest .mcpb bundle
from the Releases page,
double-click it, and paste your key when prompted.
Requires Node.js 22 when running via npx.
Tools
Sixteen tools over one shared layer. The HTTP / SSL / DNS diagnostics work with no account and no API key — point any client at the server and start checking.
Projects & monitors
Tool | What it does |
| List the projects your key can access (with notification channels and groups). |
| Create a new project (account-scoped key with |
| Update a project's name or description (partial patch). |
| Create a monitor — cron, heartbeat, or HTTP uptime. |
| List a project's monitors with type, status, and schedule. |
| Fetch one monitor by id, with its full configuration. |
| Update an existing monitor (partial patch). |
| Pause a monitor (stops checks and alerts). |
| Resume a paused monitor. |
Observe & triage
Tool | What it does |
| Recent pings, checks, and response times for a monitor. |
| Project-wide uptime / SLA rollup across monitors. |
| List incidents (downtime and missed runs), filterable by status or monitor. |
| Get, acknowledge, or resolve an incident. |
Diagnostics — no account required
Tool | What it does |
| Check a URL's reachability, status code, and response time. |
| Inspect a TLS certificate — validity, expiry, and issuer. |
| Resolve a hostname and report its DNS records. |
Example prompts
List all my monitors and their current status.
Create a cron monitor for my nightly backup that runs every day at 02:00 UTC.
What's my uptime this month?
Show me open incidents and acknowledge the most recent one.
Is https://example.com up right now? # no account needed
Is the SSL certificate for example.com about to expire? # no account neededTry it with zero setup
The check_http, check_ssl, and check_dns tools need no Drumbeats account or API
key. Add the server, leave DRUMBEATS_API_KEY unset, and ask "Is my site up?" before
you sign up. When you're ready for continuous monitoring and alerts,
create a free account.
Configuration
Variable | Required | Default | Description |
| For the monitoring tools | — | Account-scoped key ( |
| No |
| The apex REST URL. The Drumbeats API is split across services by path prefix ( |
| No |
| Self-host override: full base URL for the |
| No |
| Self-host override: full base URL for the |
| No |
| Self-host override: full base URL for the |
Development
Requires the Node version in .nvmrc.
npm ci # install dependencies
npm run build # compile TypeScript to dist/
npm run lint # Biome lint + format check
npm test # run the test suiteSee CONTRIBUTING.md for the contribution workflow and SECURITY.md for the security policy. This is a security product — please report vulnerabilities privately.
Links
Product: drumbeats.io · sign up
License
Apache-2.0 © Lucky S Software. See NOTICE.
A product by Lucky S Software.
Available Tools
16 toolscheck_dnsCheck DNSARead-only
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?".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| hostname | Yes | The hostname to resolve, e.g. example.com (a domain, not an IP). |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| records | Yes | |
| all_failed | Yes | |
| checked_at | Yes | |
| check_region | Yes | |
| hostname_checked | Yes | |
| resolution_errors | Yes |
TDQS
A4.3/5.0
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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-only
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.
ParametersJSON Schema
| 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
ParametersJSON 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
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world; the description adds that no account is needed and that the tool reports status code and response time, providing helpful context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose and provide immediate value without any unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with full schema descriptions, annotations, and likely an output schema, the description is complete and provides all necessary context without gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with well-described parameters; the description does not add extra meaning beyond what is already in the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool checks HTTP(S) URL reachability and reports status code and response time, clearly distinguishing it from sibling tools like check_dns and check_ssl.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes it works without an account or API key, implying suitability for quick pre-signup checks, but does not explicitly contrast with when to use alternatives like check_dns or check_ssl.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_sslCheck SSLARead-only
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?".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | TLS port (default 443). | |
| hostname | Yes | The hostname to inspect, e.g. example.com (no scheme). |
Output Schema
ParametersJSON 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
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. Description reinforces no authentication requirement and explains what the tool inspects, adding value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and immediate utility. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description covers key return aspects (validity, expiry, issuer) and use case. Sufficient for a simple inspection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. Description adds no additional detail beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Inspect a host's TLS/SSL certificate' with specific details like validity, expiry date, and issuer. Distinct from sibling tools like check_dns and check_http.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indicates no account/API key needed and provides a common use case ('Is my SSL certificate about to expire?'). Lacks explicit guidance on when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_monitorCreate monitorA
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.
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| monitor | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only show readOnlyHint=false. Description adds significant behavioral details: JOB_BASIC schedule is ignored, grace_period/schedule_tolerance don't apply, max_duration_seconds as hard timeout for JOB_BASIC, uptime_headers stripped on cross-origin, etc. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points and type-specific details; front-loaded with purpose. Slightly lengthy but each sentence adds value. Could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all 29 parameters with context, explains type-specific behaviors, references related tools (list_projects). Output schema exists so return values are covered. Complete for a complex creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even with 100% schema coverage, description adds crucial context: schedule format per type, uptime_headers behavior on redirects, JOB_BASIC-specific timeout semantics, uptime_locations constraints, etc. Goes far beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with 'Create a Drumbeats monitor' and details four specific types, distinguishing it clearly from sibling tools like list_monitors, update_monitor, pause_monitor, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to choose the correct type based on use case (cron, event-driven, heartbeat, uptime) and how to wire alerts, but doesn't explicitly state when not to use this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_projectCreate projectA
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The project name. | |
| description | No | Optional project description. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| project | Yes |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-readonly and non-destructive. Description adds concrete behavioral details: requires 'manage_projects' scope, returns project ID, may hit plan limit with error pointing to upgrade path. This is useful beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each serving a distinct purpose: action, definition, prerequisites, return behavior and limit warning. No fluff, well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists (context signals), description adequately covers prerequisites, return value (project ID), limit behavior, and relationship to sibling tools like 'create_monitor'. No obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters (name, description). Description does not add new parameter details beyond schema, but provides useful context about the project entity. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new Drumbeats project') and defines the resource ('groups monitors, incidents, and notification settings'). It distinguishes from siblings like 'create_monitor' by noting the returned project ID can be passed to that tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: use to create a project before adding monitors, mentions required API scope, and warns about plan limits. Does not explicitly exclude cases or contrast with alternatives like 'update_project', but 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-only
Get a single Drumbeats monitor by id, including its type, status, schedule, and alerting metadata.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| monitor_id | Yes | The monitor id (from list_monitors). |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| monitor | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is known. The description adds behavioral context by specifying the returned attributes (type, status, schedule, alerting metadata), which goes beyond the annotation. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant information. Every part is necessary and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one parameter and an output schema (not shown but present), the description covers the essential aspects: what is retrieved and the key field. No additional context needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (monitor_id). The description adds value by stating 'from list_monitors', providing provenance for the parameter value beyond the schema's type and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get a single Drumbeats monitor by id') and what is included ('type, status, schedule, and alerting metadata'). It distinguishes from siblings like list_monitors (which retrieves all monitors) and update_monitor (which modifies).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: use when needing details of a specific monitor. It does not explicitly state when not to use or provide alternatives, but the context is clear given the sibling tools and the nature of the operation.
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-only
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?".
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| kind | Yes | |
| monitor_id | Yes |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds value by explaining the multi-kind behavior and default kind, providing behavioral context beyond the read-only nature. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the action and resource, with zero wasted words. It efficiently conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the core functionality, it lacks explicit mention that 'page' and 'limit' only apply to 'pings' and 'period_hours' only to 'response_times', which is nuanced but important for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for each parameter. The description adds minimal extra meaning beyond summarizing the kind enum. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('monitor's recent history'), and clarifies that the tool supports multiple history types via the 'kind' argument. This clearly distinguishes it from sibling tools like 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Use it to answer what happened with this monitor lately?' It implies context for usage but does not explicitly mention when not to use it or alternatives among siblings.
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-only
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?".
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| overall | No | |
| monitors | No | |
| period_hours | No |
TDQS
A4.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already confirm readOnlyHint=true, so the description's read-only nature is consistent. The description adds temporal context (look-back window) and data points, but does not disclose potential timeouts, pagination, or caching behavior. With annotations covering safety, this is adequate but not outstanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first efficiently lists the action and output, the second anchors with a relatable question. Every word contributes, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, scope (project across all monitors), returned data types, and temporal parameter. An output schema exists (not shown) to detail return format, so the description is complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds value by explaining project_id's origin ('from list_projects') and giving practical guidance for period_hours (default 24, use 720 for 'this month'), which goes beyond schema constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a project-level uptime/SLA summary across all monitors, listing specific metrics (overall uptime percentage, per-monitor details, check counts, response times). It provides a relatable use case ('what is my uptime this month?') and naturally distinguishes from siblings like get_monitor (single monitor) or list_monitors (no summary).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use for project-level summary across monitors, with a concrete example query. However, it does not explicitly state when not to use it or directly compare with alternatives, leaving the agent to infer from sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_incidentsList incidentsARead-only
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.
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| incidents | Yes | |
| pagination | Yes |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds that results are newest-first and paginated, and explains incidents as downtime/missed-run events. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the main action and then provide key details. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential aspects: what is returned (incidents), ordering, pagination, required parameter, optional filters. With output schema present, this description is complete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description repeats filter options from schema and adds the project_id prerequisite hint, but does not significantly expand on parameter meaning beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states it lists incidents (downtime/missed-run events) for a Drumbeats project, with ordering and filtering. Clearly distinguishes from sibling tools like manage_incident or get_monitor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Sets a clear prerequisite: requires project_id from list_projects. Mentions filtering options. Does not explicitly exclude misuse cases, but context from siblings and description is sufficient for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_monitorsList monitorsARead-only
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.
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| monitors | Yes |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with readOnlyHint annotation, adding detail about returned metadata. No contradictions or hidden behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description need not detail returns; it mentions key metadata. Prerequisite and workflow are covered. Highly complete for a simple listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the parameter with a description already, so the tool description does not add new semantic meaning beyond that. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all monitors in a project with specific metadata (type, status, schedule). It distinguishes from sibling tools like get_monitor, create_monitor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisite (project_id from list_projects) and purpose (to find monitor id before fetching details/history/incidents), guiding when and how to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_projectsList projectsARead-only
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.
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| projects | Yes |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true. Description adds context by stating 'returns each project id, name, plan, and basic metadata' and explains the effect of include parameter. No contradictions. Good addition over annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and return content, second explains optional parameter use case. No wasted words. Information is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with one optional param and output schema present. Description covers purpose, return fields, optional param usage, and provides context for when to use it. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage (include param described). Description adds value by explaining why include is useful: 'needed to wire alerts when creating a monitor.' This goes beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List all Drumbeats projects...' with specific verb and resource. It mentions what is returned (id, name, plan, basic metadata) and distinguishes it from siblings like create_project or list_monitors by focusing on listing projects for finding target ids.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit advice: 'use it to find the target project id before creating or querying monitors.' Also explains when to pass include parameter: 'Pass include=["channels","groups"] ... needed to wire alerts when creating a monitor.' This tells the agent both the primary use and optional extension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
manage_incidentManage incidentAIdempotent
Triage a Drumbeats incident: get its details, acknowledge it, or resolve it. One tool with an "action" argument.
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| action | Yes | |
| incident | Yes |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the three actions and their effects (acknowledge marks as worked on, resolve closes it), which adds context beyond annotations. However, it does not detail idempotency implications or side effects of repeating actions, though annotations already provide idempotentHint=true. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and key actions, second reinforces the action argument. Front-loaded, no filler, every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with full schema descriptions, an output schema, and clear enum, the description covers the core use cases adequately. Missing only nuanced conditional behavior (e.g., acknowledging an already acknowledged incident), but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful explanations for each action (get, acknowledge, resolve) and clarifies that incident_id comes from list_incidents. Schema coverage is 100%, and the description enhances understanding beyond the enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Triage' and the resource 'incident', listing the specific actions (get, acknowledge, resolve). It distinguishes itself from sibling tools like list_incidents and check_* by unifying multiple incident management actions into one tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the actions and that it's a single tool with an action argument, but lacks explicit guidance on when to use this tool versus alternatives like list_incidents for fetching, or when not to use it. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pause_monitorPause monitorAIdempotent
Pause a monitor by id. It stops running checks and sending alerts until resumed.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| monitor_id | Yes | The monitor id (from list_monitors). |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| monitor | Yes |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint false and idempotentHint true. The description adds context by specifying that checks and alerts are stopped until resumed, which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the action and effect, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description sufficiently covers purpose and effect for a simple one-parameter tool with an output schema. It could mention prerequisites (e.g., monitor must exist), but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already explains the parameter ('The monitor id (from list_monitors)'). The tool description adds no additional parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Pause a monitor by id') and the effect ('stops running checks and sending alerts until resumed'). It distinguishes from sibling tools like 'resume_monitor'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for temporarily stopping monitoring but does not explicitly state when to use or avoid this tool, nor does it mention alternatives like 'resume_monitor'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resume_monitorResume monitorAIdempotent
Resume a paused monitor by id.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| monitor_id | Yes | The monitor id (from list_monitors). |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| monitor | Yes |
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true, and the description implies a state change but does not disclose additional traits like prerequisites (e.g., monitor must be paused) or error cases. Annotations carry the burden here, so score is adequate but not enhanced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is appropriately sized and front-loaded, with no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, clear annotations, and an output schema, the description is sufficiently complete. It could mention the prerequisite that the monitor must be paused, but overall it provides enough context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with the parameter 'monitor_id' already described in the schema. The description adds no additional semantic meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('resume') and the resource ('monitor'), and it directly contrasts with the sibling 'pause_monitor', making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'pause_monitor' or under what conditions it is appropriate to resume a monitor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_monitorUpdate monitorAIdempotent
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.
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| monitor | Yes |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors beyond annotations: partial update semantics, type change recalculates schedule, and 'UP' status forces recovery resetting counters. No contradiction with annotations (idempotentHint=true is consistent).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, but the structure mixes guidelines and behavioral notes. It could be slightly more organized, but it is still efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 30 parameters and complex update behavior, the description covers essential behavioral aspects (partial update, type changes, status resets). The schema and output schema provide additional completeness, making the description sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining cross-parameter effects (e.g., 'uptime_* fields apply to UPTIME_HTTP monitors', 'switching type recalculates the schedule'). This goes beyond schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update', the resource 'Drumbeats monitor', and the partial update pattern ('provide monitor_id plus only the fields to change'). It distinguishes from sibling tools like create_monitor by focusing on existing monitors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions when to use alternatives: 'Set status to PAUSED or UP to pause/resume (or use pause_monitor / resume_monitor).' This provides clear context for choosing the appropriate tool for pausing/resuming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_projectUpdate projectAIdempotent
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.
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| project | Yes |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and destructiveHint=false. The description adds that it requires an API key with manage_projects scope and MANAGER or OWNER role, providing important behavioral context beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences), well-structured, and front-loaded with the essential information. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the parameters, annotations, and presence of an output schema, the description is complete. It covers purpose, prerequisites, and field usage, making it fully informative for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented in the schema. The description adds value by clarifying that only provided fields will be changed and that null clears the description, which is not fully explicit in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing Drumbeats project, specifying the required project_id and the fields that can be changed (name and/or description). This distinguishes it from create_project and other siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (update existing project) and what to provide (project_id plus only fields to change). It also specifies required API scope and role. It doesn't explicitly mention when not to use or compare to alternatives, but context is sufficient.
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.
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
A4.1/5.0
Scored across 16 tools
Disambiguation4/5
Most tools map cleanly to distinct resources and actions, but pause_monitor and resume_monitor overlap with update_monitor's status field, creating minor ambiguity. The type/kind/action parameters in create_monitor, get_monitor_history, and manage_incident are well documented and prevent confusion.
Naming Consistency5/5
All tools follow a consistent snake_case verb_noun pattern (list_projects, create_monitor, get_uptime_summary, check_ssl). Verb choices are predictable and resource names are stable throughout.
Tool Count4/5
Sixteen tools is slightly above the ideal range, especially with three no-account diagnostic checks that sit outside the core monitoring workflow. Overall the count is still reasonable for a monitoring platform with projects, monitors, incidents, and quick checks.
Completeness4/5
Core lifecycle coverage is solid: projects and monitors have create/read/update, monitors have pause/resume/history, and incidents have list/triage. The main gap is the absence of delete/archive operations for projects or monitors, which agents can work around with pause or update but may need for cleanup.
Maintenance
ActivitySlowing
ResponsivenessNo issues
Related MCP Connectors
- mttrlyOAuthcom.mttrly
AI-powered incident management and server monitoring via MCP.
- sentinelOAuthio.rootstuff
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.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Related MCP Servers
uptrack-mcpofficial
AlicenseNot gradedqualityDmaintenanceMCP server for Uptrack uptime monitoring. Manage monitors and incidents from AI agents like Claude, ChatGPT, and Cursor.5 npmMIT- FlicenseBqualityDmaintenanceMCP server for Loggy that enables AI coding assistants to manage heartbeats, status pages, uptime monitors, feature flags, and logs via natural language.15-
- AlicenseAqualityDmaintenanceAn MCP server that exposes live network monitoring data as Resources and diagnostic capabilities as Tools, letting AI assistants query network health conversationally.6MIT