Vendor status pages, TLS cert inspection, DNS propagation checks, and incident-response playbooks.
Call this server's tools from your browser. Nothing to install.
Requests go through mcptry because browsers can't call most MCP servers directly. Header values are sent to the server for that request only and are never stored or logged.
Tool list from our last check. Connect live to refresh it.
Inspect SSL/TLS certificate health for one or more domains by performing a real TLS handshake. Works for any internet-accessible domain — no vendor registry required. Reports days to expiry (flagged at < 30 days warning and < 7 days critical), certificate subject and SANs, issuer, hostname coverage, chain-trust verification, TLS protocol version negotiated (flags TLS 1.0/1.1 as insecure — a server offering only those is still inspected), cipher suite, and HSTS presence when the port answers HTTP. The handshake completes even for a certificate clients would reject, so a broken certificate is reported rather than hidden behind a connection error: a hostname mismatch surfaces in cert.hostname_verification_error and a chain-trust failure (self-signed, untrusted root) in cert.authorization_error, both status "critical". Non-HTTP TLS ports (IMAPS 993, SMTPS 465, DNS over TLS 853) are graded the same way, with HSTS reported as not checked. If a domain fails to connect at all, check devops_check_dns first — the name may not resolve. When a certificate fails to issue or renew, run devops_check_dns with record_types ["CAA"] to see which certificate authorities the domain allows.
Hosts to inspect. The first 10 entries are inspected; up to 100 are accepted, and entries past the 10th come back uninspected and verbatim in deferred_domains, to resend in another call. Each entry is read as one host: surrounding whitespace and letter case are ignored, a scheme, path, query, or fragment is dropped, an internationalized name is converted to its ASCII form ("münchen.de" → "xn--mnchen-3ya.de"), and a port written on the entry is used for that entry in place of "port". An entry with no single host — a user name before "@", a bad port, or a malformed label — gets its own result with status "error" and is never connected to; the other entries still run.
TLS port for entries that do not carry their own. Defaults to 443. Use 8443 or custom ports for non-standard HTTPS endpoints, or 993, 465, 853, and the like for other TLS services. A port written on an entry ("example.com:8443") wins for that entry.
Time limit in milliseconds for each domain, covering the connection, the handshake, a second handshake with TLS 1.0/1.1 enabled when the server offers nothing newer, and the HSTS request. A port that completes the handshake and then sends nothing is reported at this limit, certificate included. At least 1000; a value over 15000 is served as 15000, and the notice says so. Defaults to 5000 unless the server is configured otherwise. Increase for slow or geographically distant endpoints.
Inspect SSL/TLS certificate health for one or more domains by performing a real TLS handshake. Works for any internet-accessible domain — no vendor registry required. Reports days to expiry (flagged at < 30 days warning and < 7 days critical), certificate subject and SANs, issuer, hostname coverage, chain-trust verification, TLS protocol version negotiated (flags TLS 1.0/1.1 as insecure — a server offering only those is still inspected), cipher suite, and HSTS presence when the port answers HTTP. The handshake completes even for a certificate clients would reject, so a broken certificate is reported rather than hidden behind a connection error: a hostname mismatch surfaces in cert.hostname_verification_error and a chain-trust failure (self-signed, untrusted root) in cert.authorization_error, both status "critical". Non-HTTP TLS ports (IMAPS 993, SMTPS 465, DNS over TLS 853) are graded the same way, with HSTS reported as not checked. If a domain fails to connect at all, check devops_check_dns first — the name may not resolve. When a certificate fails to issue or renew, run devops_check_dns with record_types ["CAA"] to see which certificate authorities the domain allows.
| Argument | Type | Description |
|---|---|---|
| port | integer | TLS port for entries that do not carry their own. Defaults to 443. Use 8443 or custom ports for non-standard HTTPS endpoints, or 993, 465, 853, and the like for other TLS services. A port written on an entry ("example.com:8443") wins for that entry. |
| domains* | array | Hosts to inspect. The first 10 entries are inspected; up to 100 are accepted, and entries past the 10th come back uninspected and verbatim in deferred_domains, to resend in another call. Each entry is read as one host: surrounding whitespace and letter case are ignored, a scheme, path, query, or fragment is dropped, an internationalized name is converted to its ASCII form ("münchen.de" → "xn--mnchen-3ya.de"), and a port written on the entry is used for that entry in place of "port". An entry with no single host — a user name before "@", a bad port, or a malformed label — gets its own result with status "error" and is never connected to; the other entries still run. |
| timeout_ms | integer | Time limit in milliseconds for each domain, covering the connection, the handshake, a second handshake with TLS 1.0/1.1 enabled when the server offers nothing newer, and the HSTS request. A port that completes the handshake and then sends nothing is reported at this limit, certificate included. At least 1000; a value over 15000 is served as 15000, and the notice says so. Defaults to 5000 unless the server is configured otherwise. Increase for slow or geographically distant endpoints. |
{
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"domains"
],
"properties": {
"port": {
"type": "integer",
"default": 443,
"maximum": 65535,
"minimum": 1,
"description": "TLS port for entries that do not carry their own. Defaults to 443. Use 8443 or custom ports for non-standard HTTPS endpoints, or 993, 465, 853, and the like for other TLS services. A port written on an entry (\"example.com:8443\") wins for that entry."
},
"domains": {
"type": "array",
"items": {
"type": "string",
"minLength": 1,
"description": "A host to inspect: a hostname (\"api.github.com\"), an IP address, a host with a port (\"example.com:8443\", \"[2606:4700:4700::1111]:853\"), or a URL (\"https://example.com/login\"), which is reduced to its host."
},
"maxItems": 100,
"minItems": 1,
"description": "Hosts to inspect. The first 10 entries are inspected; up to 100 are accepted, and entries past the 10th come back uninspected and verbatim in deferred_domains, to resend in another call. Each entry is read as one host: surrounding whitespace and letter case are ignored, a scheme, path, query, or fragment is dropped, an internationalized name is converted to its ASCII form (\"münchen.de\" → \"xn--mnchen-3ya.de\"), and a port written on the entry is used for that entry in place of \"port\". An entry with no single host — a user name before \"@\", a bad port, or a malformed label — gets its own result with status \"error\" and is never connected to; the other entries still run."
},
"timeout_ms": {
"type": "integer",
"default": 5000,
"maximum": 9007199254740991,
"minimum": 1000,
"description": "Time limit in milliseconds for each domain, covering the connection, the handshake, a second handshake with TLS 1.0/1.1 enabled when the server offers nothing newer, and the HSTS request. A port that completes the handshake and then sends nothing is reported at this limit, certificate included. At least 1000; a value over 15000 is served as 15000, and the notice says so. Defaults to 5000 unless the server is configured otherwise. Increase for slow or geographically distant endpoints."
}
},
"additionalProperties": false
}Resolve DNS records for one or more domains across multiple public resolvers and compare what each resolver returned. Works for any domain — no vendor registry required. Reports records found (A/AAAA/CNAME/MX/TXT/NS/CAA/SOA), resolution latency per resolver, and a typed outcome per resolver and record type so "the domain does not exist" (nxdomain), "the resolver could not answer" (servfail), and "no record of this type" (nodata) stay distinguishable. Resolver disagreements are reported without asserting a cause: partial_resolution (some resolvers answered, others returned nothing) points at a real propagation or resolver problem, while value_variation (every resolver answered with different values) is the normal steady state for anycast and geo-steered domains. Pair with devops_check_certs when a domain resolves but TLS to it is failing.
| Argument | Type | Description |
|---|---|---|
| domains* | array | Domain names to query. The first 10 entries are queried; up to 100 are accepted, and entries past the 10th come back unqueried and verbatim in deferred_domains, to resend in another call. Each entry is read as one name: surrounding whitespace and letter case are ignored, a scheme, port, path, query, or fragment is dropped, and an internationalized name is converted to its ASCII form ("münchen.de" → "xn--mnchen-3ya.de"); a trailing dot and underscore labels are kept. An entry that is not a domain name — an IP address, a user name before "@", a bad port, or a malformed label — gets its own result with "error" set and is never queried; the other entries still run. |
| resolvers | array | Resolver IP addresses to query. Defaults to Google (8.8.8.8), Cloudflare (1.1.1.1), and Quad9 (9.9.9.9). An empty array uses the same defaults. Add custom resolvers to test resolver-specific behavior. A resolver listed more than once — the same address and port, however written ("8.8.8.8" and "8.8.8.8:53") — is queried once, under its first spelling. The first 5 distinct resolvers are queried; up to 20 entries are accepted, and the rest come back unqueried in deferred_resolvers, to resend with the same domains in another call. Each must be an IP literal, not a hostname; resolvers in private, loopback, or cloud-metadata ranges are rejected unless DEVOPS_STATUS_ALLOW_PRIVATE_TARGETS=true. |
Fetch incident history and scheduled maintenance windows for a vendor. Returns full incident timeline — each investigator update, affected components, and resolution. Filter by status to focus on active incidents (use before deploy), resolved history (for postmortem), or upcoming maintenance windows, and narrow further with match (words in the title or affected component names) and since/until (a start-date range) — all applied before paging, so totals count only what they keep. Page through long histories with limit + offset — a truncated result discloses the total and returns the value to page with in nextOffset. Each response is held to 64,000 bytes per surface: a page can stop short of limit at that budget (the paging fields and notice say so), and an incident too large on its own keeps only its newest updates, with updates_omitted counting the rest — full_updates: true returns them all. Some vendor feeds cap their own history: when upstreamCeiling is present the vendor API returned everything it will serve, and older incidents are not reachable at a higher offset. On Atlassian Statuspage vendors, since (a date) also reads the status page's quarterly history archive back to that date, or 24 months back at most, where the page publishes one — not on a vendor that covers only part of a shared page, such as "sendgrid"; those records are marked source: "history" and carry the title, impact, start and end times, and final update message only. An empty result, or a history read that stopped short of since, explains itself in notice.
| Argument | Type | Description |
|---|---|---|
| limit | integer | Maximum incidents to return per call, at least 1. A value over 50 is served as 50, and the notice says so. Page through longer history with offset rather than raising this. |
| match | string | Words to look for in each incident's title and affected component names, ignoring case and punctuation ("git-operations" reads as "git operations"). An incident is kept when every word appears, as all or part of a word, in its title or in one of its component names. History-archive records, and vendors that publish no components, match on title alone. Applied before limit/offset, so totals and paging count only the matches. Leave blank to keep every incident. |
List vendors in the built-in registry, optionally filtered by category or name search. Returns slug, display name, category, and status page URL for each entry. Use to discover the correct slug to pass to other tools, or to see which vendors are available before configuring a stack.
| Argument | Type | Description |
|---|---|---|
| query | string | Substring search against vendor slug and display name. Case-insensitive; surrounding whitespace is ignored. E.g., "cloud", "auth", "slack". |
| category | string | Filter to one category: cloud, cdn-edge, dev-platform, data, comms, auth, monitoring, or ai. |
{
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"properties": {
"query": {
"type": "string",
"description": "Substring search against vendor slug and display name. Case-insensitive; surrounding whitespace is ignored. E.g., \"cloud\", \"auth\", \"slack\"."
},
"category": {
"enum": [
"cloud",
"cdn-edge",
"dev-platform",
"data",
"comms",
"auth",
"monitoring",
"ai"
],
"type": "string",
"description": "Filter to one category: cloud, cdn-edge, dev-platform, data, comms, auth, monitoring, or ai."
}
},
"additionalProperties": false
}Check the current health status for one or more vendors. Accepts registered vendor slugs (e.g., "github", "aws", "gcp", "gitlab") or raw Atlassian Statuspage base URLs. Registry entries are served by each vendor's native status API (Statuspage, Status.io, Slack, AWS Health, Google Cloud Service Health, Azure status, Azure DevOps status, Firehydrant) and normalized to one shape. Returns per-vendor operational indicator (none = all clear, minor, major, critical, maintenance = scheduled window), degraded components, and active incidents. Use mode: "detailed" for component lists and maintenance windows, narrowed with component_filter and bounded by component_limit. Batch-friendly — pass a list to check your full stack in one call; up to 20 vendors are checked per call, and any past the 20th come back in deferred_vendors to resend. A vendor that cannot be resolved or reached is reported in its own result row, so one bad entry never discards the rest. Every vendor with an active problem gets a pre-filled devops_suggest_action call in nextToolSuggestions.
| Argument | Type | Description |
|---|---|---|
| mode | string | summary: indicator + degraded components + active incidents only. detailed: adds the component list and scheduled maintenance windows. |
| vendors* | array | Vendor slugs from the built-in registry (e.g., "github", "aws") or raw Atlassian Statuspage base URLs (non-Statuspage backends are supported via registry slugs only). Mix freely. Use devops_list_vendors to discover available slugs. The first 20 are checked, in the order given; entries past the 20th are returned unchecked in deferred_vendors to resend in another call. Lists longer than 100 are rejected. |
| component_limit | integer | Maximum components returned per vendor in detailed mode, at least 1. A value above 500 is reduced to 500, and notice says so. Large status pages publish hundreds of components, so a multi-vendor batch at a high limit returns a very large response; narrow with component_filter instead where possible. |
Return an incident-response playbook tailored to a vendor degradation, with pre-filled follow-up tool calls. Synthesizes category-specific guidance (cloud, CDN, dev-platform, auth, etc.) from built-in incident knowledge and the provided context. Use after devops_status_check or devops_get_incidents surfaces a problem to determine what to investigate next.
| Argument | Type | Description |
|---|---|---|
| vendor* | string | Vendor slug, display name, or raw status page URL (e.g., "cloudflare", "Amazon Web Services"). Used to tailor category-specific guidance (CDN outage vs. CI/CD outage vs. auth provider outage). A name that matches no registry vendor gets a devops_list_vendors search as its first follow-up instead of an incidents call. |
| your_domain | string | Your own domain or service URL. When provided, nextToolSuggestions will be pre-filled with your domain for cert and DNS checks. |
| incident_summary | string | Latest incident description or update body from devops_get_incidents. Paste the most recent update to get more targeted advice. |
| vendor_indicator | string | Overall vendor status indicator from a prior devops_status_check call (its indicator field). When provided, the playbook leads with severity-tailored urgency guidance. Omit if status has not been checked yet. |
| affected_components | array | Component names affected (from devops_status_check degraded_components or devops_get_incidents affected_components). Values pre-filled by devops_status_check read "Group / Leaf" for a component the status page files under a group. Used to tailor suggestions to the impacted subsystem. |
Check the health of a named vendor stack — a saved list of vendors representing your infrastructure dependencies. On the first call, provide vendors to define the stack; subsequent calls can omit vendors to reuse the saved list. Stacks are saved per authenticated caller, or per local server process; a shared deployment that does not authenticate callers saves nothing, so there vendors is required on every call and the response says so. Up to 20 vendors are saved per stack and checked per call; use several stack names for a larger set. Returns a unified health snapshot with an aggregate rollup plus per-vendor detail. A vendor that cannot be resolved or reached is reported in its own row and left out of the saved stack, so one bad entry never discards the sweep. Every vendor with an active problem gets a pre-filled devops_suggest_action call in nextToolSuggestions. Ideal for morning status checks or pre-deploy sweeps. Multiple stacks can coexist (e.g., "production", "staging").
| Argument | Type | Description |
|---|---|---|
| mode | string | summary: indicator + degraded components + active incidents. detailed: adds component lists and maintenance windows. |
| vendors | array | Vendor slugs (e.g., "github", "aws") or raw Atlassian Statuspage base URLs. When provided, saves this list as the stack where stacks are saved; a list longer than 20 is then rejected and nothing is saved. When omitted, uses the previously saved list for stack_name; required on every call on a deployment that does not authenticate callers, which saves no stacks — there the first 20 are checked and the rest return in deferred_vendors. Lists longer than 100 are rejected. |
| stack_name | string | Name for this vendor stack. Defaults to "default". Use distinct names to manage multiple stacks (e.g., "production", "data-layer"). Letters, digits, hyphens, and underscores, optionally separated by single dots or slashes ("prod.eu", "team/prod"); 1-64 characters. No spaces or colons. |
| timeout_ms | integer | Time limit in milliseconds for each domain+resolver pair, covering every requested record type and any retry over TCP. A resolver that has not answered within it reports "timeout" for the unanswered types. At least 1000; a value over 10000 is served as 10000, and the notice says so. Defaults to 3000 unless the server is configured otherwise. |
| record_types | array | DNS record types to resolve. Defaults to A, AAAA, MX, and TXT. An empty array uses the same defaults. A type listed more than once is queried once. Add NS to check nameserver delegation. Add CNAME when investigating redirect chains. Add CAA when a certificate will not issue or renew: it lists the certificate authorities allowed to issue for the name. CAA is reported for the exact name only; a CA that finds none there checks the parent domains, so no CAA at a subdomain does not mean any CA may issue. Add SOA to compare zone serials across resolvers. SOA answers only at a zone apex, so a name below it returns nodata (a name that is a CNAME returns the SOA of its target). A serial difference means a zone change has not reached every resolver only when those resolvers report the same primary nameserver; a different primary means more than one DNS provider serves the zone. |
{
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"domains"
],
"properties": {
"domains": {
"type": "array",
"items": {
"type": "string",
"minLength": 1,
"description": "A domain name to query (e.g., \"github.com\", \"_dmarc.example.com\"). A URL or a host:port is reduced to its host."
},
"maxItems": 100,
"minItems": 1,
"description": "Domain names to query. The first 10 entries are queried; up to 100 are accepted, and entries past the 10th come back unqueried and verbatim in deferred_domains, to resend in another call. Each entry is read as one name: surrounding whitespace and letter case are ignored, a scheme, port, path, query, or fragment is dropped, and an internationalized name is converted to its ASCII form (\"münchen.de\" → \"xn--mnchen-3ya.de\"); a trailing dot and underscore labels are kept. An entry that is not a domain name — an IP address, a user name before \"@\", a bad port, or a malformed label — gets its own result with \"error\" set and is never queried; the other entries still run."
},
"resolvers": {
"type": "array",
"items": {
"type": "string",
"minLength": 1,
"description": "A resolver IP literal — IPv4 (\"8.8.8.8\"), IPv6 (\"2001:4860:4860::8888\"), or either with a port (\"1.1.1.1:53\", \"[2001:4860:4860::8888]:53\"). A hostname is rejected."
},
"default": [
"8.8.8.8",
"1.1.1.1",
"9.9.9.9"
],
"maxItems": 20,
"description": "Resolver IP addresses to query. Defaults to Google (8.8.8.8), Cloudflare (1.1.1.1), and Quad9 (9.9.9.9). An empty array uses the same defaults. Add custom resolvers to test resolver-specific behavior. A resolver listed more than once — the same address and port, however written (\"8.8.8.8\" and \"8.8.8.8:53\") — is queried once, under its first spelling. The first 5 distinct resolvers are queried; up to 20 entries are accepted, and the rest come back unqueried in deferred_resolvers, to resend with the same domains in another call. Each must be an IP literal, not a hostname; resolvers in private, loopback, or cloud-metadata ranges are rejected unless DEVOPS_STATUS_ALLOW_PRIVATE_TARGETS=true."
},
"timeout_ms": {
"type": "integer",
"default": 3000,
"maximum": 9007199254740991,
"minimum": 1000,
"description": "Time limit in milliseconds for each domain+resolver pair, covering every requested record type and any retry over TCP. A resolver that has not answered within it reports \"timeout\" for the unanswered types. At least 1000; a value over 10000 is served as 10000, and the notice says so. Defaults to 3000 unless the server is configured otherwise."
},
"record_types": {
"type": "array",
"items": {
"enum": [
"A",
"AAAA",
"CNAME",
"MX",
"TXT",
"NS",
"CAA",
"SOA"
],
"type": "string"
},
"default": [
"A",
"AAAA",
"MX",
"TXT"
],
"description": "DNS record types to resolve. Defaults to A, AAAA, MX, and TXT. An empty array uses the same defaults. A type listed more than once is queried once. Add NS to check nameserver delegation. Add CNAME when investigating redirect chains. Add CAA when a certificate will not issue or renew: it lists the certificate authorities allowed to issue for the name. CAA is reported for the exact name only; a CA that finds none there checks the parent domains, so no CAA at a subdomain does not mean any CA may issue. Add SOA to compare zone serials across resolvers. SOA answers only at a zone apex, so a name below it returns nodata (a name that is a CNAME returns the SOA of its target). A serial difference means a zone change has not reached every resolver only when those resolvers report the same primary nameserver; a different primary means more than one DNS provider serves the zone."
}
},
"additionalProperties": false
}| since | any | Earliest start date to include, as YYYY-MM-DD (UTC). Accepted with filter "all" or "resolved". Incidents that started before it are left out, and limit/offset page the rest. On Atlassian Statuspage vendors it also reads the status page's quarterly history archive back to this date, reaching incidents older than the 50 the status API serves — except on a vendor that covers only part of a shared status page (such as "sendgrid" on Twilio's page), whose archive records carry no components to narrow by. The archive is read back 24 months at most: for an earlier date, older records come only from what the status API still returns (such as completed maintenance windows), and the notice gives the date the archive was read back to. Omit to read only the status API. |
| until | any | Latest start date to include, as YYYY-MM-DD (UTC) — the whole day, so until equal to since returns that one day. Accepted with filter "all" or "resolved", and on or after since. Incidents that started after it are left out before limit/offset page the rest. It reads no history archive on its own: set since as well to reach incidents older than the status API returns, through an archive read back 24 months at most. |
| filter | string | all: incidents plus scheduled maintenances. active: only incidents with status investigating/identified/monitoring. resolved: only fully resolved incidents. scheduled: only scheduled maintenance windows. Not every vendor backend serves every filter — "aws" lists a resolved event only until it drops off its feed, "azure" lists open items only (never resolved), and "aws", "azure", "azure-devops", "gcp", and "slack" publish no maintenance windows. An empty result names which case applied. |
| offset | integer | Number of matching incidents to skip before applying limit, for paging through history. 0 (default) returns the most recent page; a truncated result returns the value to use next in the nextOffset field. Raising offset past the number of matches returns an empty list and says so. |
| vendor* | string | Vendor slug (e.g., "github", "aws") or raw Atlassian Statuspage base URL. Use devops_list_vendors to find slugs. |
| full_updates | boolean | Return every update of an incident that is too large for the response size budget on its own, instead of only its newest updates. Default false. Pair it with limit: 1 and the offset the notice names; the response can then run past the budget. |
{
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"vendor"
],
"properties": {
"limit": {
"type": "integer",
"default": 20,
"maximum": 9007199254740991,
"minimum": 1,
"description": "Maximum incidents to return per call, at least 1. A value over 50 is served as 50, and the notice says so. Page through longer history with offset rather than raising this."
},
"match": {
"type": "string",
"maxLength": 200,
"description": "Words to look for in each incident's title and affected component names, ignoring case and punctuation (\"git-operations\" reads as \"git operations\"). An incident is kept when every word appears, as all or part of a word, in its title or in one of its component names. History-archive records, and vendors that publish no components, match on title alone. Applied before limit/offset, so totals and paging count only the matches. Leave blank to keep every incident."
},
"since": {
"anyOf": [
{
"type": "string",
"const": ""
},
{
"type": "string",
"format": "date",
"pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
"description": "Earliest start date to include, as YYYY-MM-DD (UTC), e.g. \"2025-10-01\"."
}
],
"description": "Earliest start date to include, as YYYY-MM-DD (UTC). Accepted with filter \"all\" or \"resolved\". Incidents that started before it are left out, and limit/offset page the rest. On Atlassian Statuspage vendors it also reads the status page's quarterly history archive back to this date, reaching incidents older than the 50 the status API serves — except on a vendor that covers only part of a shared status page (such as \"sendgrid\" on Twilio's page), whose archive records carry no components to narrow by. The archive is read back 24 months at most: for an earlier date, older records come only from what the status API still returns (such as completed maintenance windows), and the notice gives the date the archive was read back to. Omit to read only the status API."
},
"until": {
"anyOf": [
{
"type": "string",
"const": ""
},
{
"type": "string",
"format": "date",
"pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
"description": "Latest start date to include, as YYYY-MM-DD (UTC), e.g. \"2025-10-31\"."
}
],
"description": "Latest start date to include, as YYYY-MM-DD (UTC) — the whole day, so until equal to since returns that one day. Accepted with filter \"all\" or \"resolved\", and on or after since. Incidents that started after it are left out before limit/offset page the rest. It reads no history archive on its own: set since as well to reach incidents older than the status API returns, through an archive read back 24 months at most."
},
"filter": {
"enum": [
"all",
"active",
"resolved",
"scheduled"
],
"type": "string",
"default": "all",
"description": "all: incidents plus scheduled maintenances. active: only incidents with status investigating/identified/monitoring. resolved: only fully resolved incidents. scheduled: only scheduled maintenance windows. Not every vendor backend serves every filter — \"aws\" lists a resolved event only until it drops off its feed, \"azure\" lists open items only (never resolved), and \"aws\", \"azure\", \"azure-devops\", \"gcp\", and \"slack\" publish no maintenance windows. An empty result names which case applied."
},
"offset": {
"type": "integer",
"default": 0,
"maximum": 9007199254740991,
"minimum": 0,
"description": "Number of matching incidents to skip before applying limit, for paging through history. 0 (default) returns the most recent page; a truncated result returns the value to use next in the nextOffset field. Raising offset past the number of matches returns an empty list and says so."
},
"vendor": {
"type": "string",
"minLength": 1,
"description": "Vendor slug (e.g., \"github\", \"aws\") or raw Atlassian Statuspage base URL. Use devops_list_vendors to find slugs."
},
"full_updates": {
"type": "boolean",
"default": false,
"description": "Return every update of an incident that is too large for the response size budget on its own, instead of only its newest updates. Default false. Pair it with limit: 1 and the offset the notice names; the response can then run past the budget."
}
},
"additionalProperties": false
}| component_filter | string | Case-insensitive substring matched against component names and their group names in detailed mode (e.g., "api" to check just the API components, or a product or region a page groups components under). Applied before component_limit, so it is the way to reach a component that the cap would otherwise omit. A filter that matches nothing for a vendor is reported in notice. Ignored in summary mode. |
{
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"vendors"
],
"properties": {
"mode": {
"enum": [
"summary",
"detailed"
],
"type": "string",
"default": "summary",
"description": "summary: indicator + degraded components + active incidents only. detailed: adds the component list and scheduled maintenance windows."
},
"vendors": {
"type": "array",
"items": {
"type": "string",
"minLength": 1,
"description": "A vendor slug (e.g., \"github\") or raw Atlassian Statuspage base URL."
},
"maxItems": 100,
"minItems": 1,
"description": "Vendor slugs from the built-in registry (e.g., \"github\", \"aws\") or raw Atlassian Statuspage base URLs (non-Statuspage backends are supported via registry slugs only). Mix freely. Use devops_list_vendors to discover available slugs. The first 20 are checked, in the order given; entries past the 20th are returned unchecked in deferred_vendors to resend in another call. Lists longer than 100 are rejected."
},
"component_limit": {
"type": "integer",
"default": 50,
"maximum": 9007199254740991,
"minimum": 1,
"description": "Maximum components returned per vendor in detailed mode, at least 1. A value above 500 is reduced to 500, and notice says so. Large status pages publish hundreds of components, so a multi-vendor batch at a high limit returns a very large response; narrow with component_filter instead where possible."
},
"component_filter": {
"type": "string",
"description": "Case-insensitive substring matched against component names and their group names in detailed mode (e.g., \"api\" to check just the API components, or a product or region a page groups components under). Applied before component_limit, so it is the way to reach a component that the cap would otherwise omit. A filter that matches nothing for a vendor is reported in notice. Ignored in summary mode."
}
},
"additionalProperties": false
}{
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"required": [
"vendor"
],
"properties": {
"vendor": {
"type": "string",
"minLength": 1,
"description": "Vendor slug, display name, or raw status page URL (e.g., \"cloudflare\", \"Amazon Web Services\"). Used to tailor category-specific guidance (CDN outage vs. CI/CD outage vs. auth provider outage). A name that matches no registry vendor gets a devops_list_vendors search as its first follow-up instead of an incidents call."
},
"your_domain": {
"type": "string",
"description": "Your own domain or service URL. When provided, nextToolSuggestions will be pre-filled with your domain for cert and DNS checks."
},
"incident_summary": {
"type": "string",
"description": "Latest incident description or update body from devops_get_incidents. Paste the most recent update to get more targeted advice."
},
"vendor_indicator": {
"enum": [
"none",
"minor",
"major",
"critical",
"maintenance"
],
"type": "string",
"description": "Overall vendor status indicator from a prior devops_status_check call (its indicator field). When provided, the playbook leads with severity-tailored urgency guidance. Omit if status has not been checked yet."
},
"affected_components": {
"type": "array",
"items": {
"type": "string"
},
"description": "Component names affected (from devops_status_check degraded_components or devops_get_incidents affected_components). Values pre-filled by devops_status_check read \"Group / Leaf\" for a component the status page files under a group. Used to tailor suggestions to the impacted subsystem."
}
},
"additionalProperties": false
}| component_limit | integer | Maximum components returned per vendor in detailed mode, at least 1. A value above 500 is reduced to 500, and notice says so. Large status pages publish hundreds of components, so a full stack at a high limit returns a very large response; narrow with component_filter instead where possible. |
| component_filter | string | Case-insensitive substring matched against component names and their group names in detailed mode (e.g., "api" to check just the API components, or a product or region a page groups components under). Applied before component_limit, so it is the way to reach a component that the cap would otherwise omit. A filter that matches nothing for a vendor is reported in notice. Ignored in summary mode. |
{
"type": "object",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"properties": {
"mode": {
"enum": [
"summary",
"detailed"
],
"type": "string",
"default": "summary",
"description": "summary: indicator + degraded components + active incidents. detailed: adds component lists and maintenance windows."
},
"vendors": {
"type": "array",
"items": {
"type": "string",
"description": "A vendor slug (e.g., \"github\") or raw Atlassian Statuspage base URL."
},
"maxItems": 100,
"description": "Vendor slugs (e.g., \"github\", \"aws\") or raw Atlassian Statuspage base URLs. When provided, saves this list as the stack where stacks are saved; a list longer than 20 is then rejected and nothing is saved. When omitted, uses the previously saved list for stack_name; required on every call on a deployment that does not authenticate callers, which saves no stacks — there the first 20 are checked and the rest return in deferred_vendors. Lists longer than 100 are rejected."
},
"stack_name": {
"type": "string",
"default": "default",
"pattern": "^[a-zA-Z0-9_-]+([./][a-zA-Z0-9_-]+)*$",
"maxLength": 64,
"minLength": 1,
"description": "Name for this vendor stack. Defaults to \"default\". Use distinct names to manage multiple stacks (e.g., \"production\", \"data-layer\"). Letters, digits, hyphens, and underscores, optionally separated by single dots or slashes (\"prod.eu\", \"team/prod\"); 1-64 characters. No spaces or colons."
},
"component_limit": {
"type": "integer",
"default": 50,
"maximum": 9007199254740991,
"minimum": 1,
"description": "Maximum components returned per vendor in detailed mode, at least 1. A value above 500 is reduced to 500, and notice says so. Large status pages publish hundreds of components, so a full stack at a high limit returns a very large response; narrow with component_filter instead where possible."
},
"component_filter": {
"type": "string",
"description": "Case-insensitive substring matched against component names and their group names in detailed mode (e.g., \"api\" to check just the API components, or a product or region a page groups components under). Applied before component_limit, so it is the way to reach a component that the cap would otherwise omit. A filter that matches nothing for a vendor is reported in notice. Ignored in summary mode."
}
},
"additionalProperties": false
}