Vendor status pages, TLS cert inspection, DNS propagation checks, and incident-response playbooks.
Scored across 7 tools
Most tools have clearly distinct purposes: certificate inspection, DNS resolution, incident history, vendor listing, status checking, action suggestions, and stack watching. The main overlap is between devops_status_check and devops_watch_stack, since both check vendor health and watch_stack is essentially a saved-list wrapper around status_check. Descriptions provide guidance, but an agent may still hesitate over which health-check tool to use for a one-off versus saved stack.
All tools share the devops_ prefix and mostly follow a verb_noun pattern: check_certs, check_dns, get_incidents, list_vendors, suggest_action, watch_stack. The exception is devops_status_check, which uses noun_verb order rather than the expected check_status pattern. This is a minor deviation and the set remains highly readable.
Seven tools is well-scoped for a DevOps status and diagnostics server. Each tool earns its place by covering a distinct part of the workflow: discovery, health checks, incident history, diagnostics, suggestions, and saved-stack monitoring. There is no obvious bloat or severe thinness.
The surface covers the core lifecycle well: vendor discovery, current status checks, incident history, certificate and DNS diagnostics, response playbooks, and saved stack monitoring. Minor gaps exist, such as no standalone tool to list or manage saved stacks, and certificate/DNS tools are diagnostic-only rather than offering remediation. These are workable gaps rather than dead ends for the stated DevOps monitoring purpose.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | 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 | Yes | 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 | No | 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. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| notice | No | Present when the call was served at a bound: hosts past the per-call cap, named in deferred_domains, or a timeout_ms over 15000 that was served as 15000. Absent otherwise. |
| results | No | Per-domain certificate inspection results. |
| deferred_domains | No | Host entries past the first 10, not inspected on this call, verbatim and in input order. Resend them in another call. Empty when every entry was inspected. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover read-only/idempotent/open-world, so the description carries the real behavioral burden and does: handshake completes even for certs clients would reject, failure surfaces in cert.hostname_verification_error / cert.authorization_error at status "critical", TLS 1.0/1.1 flagged insecure, HSTS reported as not checked on non-HTTP ports. These are non-obvious behaviors an agent could not infer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose and the handshake mechanism before the failure-mode detail, and the sibling routing lands at the end where it is most actionable. It is dense and long (~250 words) with a few clauses that could be tightened, but almost every sentence carries operational information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-field explanations are unnecessary; the description instead covers the edge cases (unresolvable names, malformed entries, refused/rejected certs, silent ports hitting the timeout) that an agent needs to interpret those results. Nothing essential to calling it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the port, domains and timeout_ms semantics are already documented thoroughly, and the baseline of 3 applies. The description adds behavioral framing (non-HTTP TLS ports graded the same way) but no parameter detail beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ("Inspect SSL/TLS certificate health") plus the mechanism ("performing a real TLS handshake") and enumerates the exact findings reported (expiry, SANs, issuer, chain trust, protocol, cipher, HSTS). That is enough for an agent to distinguish it from devops_check_dns, which it names explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit routing rules with conditions: "If a domain fails to connect at all, check devops_check_dns first — the name may not resolve" and "When a certificate fails to issue or renew, run devops_check_dns with record_types [\"CAA\"]". Both an alternative and the trigger that selects it are spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| domains | Yes | 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 | No | 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 | No | 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 | No | 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. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| notice | No | Present when the call was served at a bound: domains or resolvers past the per-call cap, named in deferred_domains and deferred_resolvers, or a timeout_ms over 10000 that was served as 10000. Absent otherwise. |
| results | No | Per-domain DNS resolution results. |
| deferred_domains | No | Domain entries past the first 10, not queried on this call, verbatim and in input order. Resend them in another call. Empty when every entry was queried. |
| deferred_resolvers | No | Distinct resolvers past the first 5, not queried on this call, verbatim and in input order. Resend them with the same domains in another call. Empty when every resolver was queried. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, openWorld), and the description adds genuine behavioral substance beyond them: typed per-resolver outcomes, the distinction between partial_resolution (a real problem) and value_variation (normal for anycast/geo-steering), and that disagreements are reported without asserting a cause. It also pre-empts false conclusions about SOA serials and subdomain CAA.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action, then scope, then output shape, then interpretation guidance, then the sibling handoff. Every sentence carries distinct information — no restatement of the name and no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description needn't enumerate return fields, and it still tells the agent what kinds of outcomes to expect and how to read them. Annotations plus 100% schema coverage plus this prose leave nothing an agent needs missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents domains, resolvers, timeout_ms, and record_types in depth including defaults, caps, and normalization rules. The description itself adds little param-level detail beyond 'one or more domains' and 'multiple public resolvers,' which is the expected baseline when the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (resolve DNS records across multiple public resolvers and compare results) and immediately sets scope with 'Works for any domain — no vendor registry required.' An agent can distinguish it from devops_check_certs, which is named as the TLS-layer counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit routing condition to a sibling: 'Pair with devops_check_certs when a domain resolves but TLS to it is failing,' and the record_types text explains when to add NS, CNAME, CAA, or SOA. It stops short of stating when not to reach for this tool versus other siblings like devops_status_check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 maintenance windows: upcoming and in-progress ones, plus completed ones on Atlassian Statuspage, Firehydrant, and Datadog vendors (Status.io vendors list upcoming and in-progress only). Narrow further with match (terms in the title or affected component names, plus location names and IDs on Google Cloud and AWS) 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; the notice says whether since reaches them. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 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 | No | Terms to look for, separated by spaces, in each incident's title, its affected component names, and, on Google Cloud and AWS, its affected location names and IDs ("us-central1", "me-south-1", "bahrain"), ignoring case. An incident is kept when every term appears in its title, one of its component names, or one of its location names or IDs, each term on its own. A one-word term matches all or part of a word. A term whose words are joined by punctuation ("eu-central-1", "git-operations", "git/operations") matches only where those words appear together, in that order, within one of those texts, anywhere in it: "eu-central-1" finds eu-central-1 but not me-central-1, and "eu-west" finds every eu-west region. 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 | No | Earliest start date to include, as YYYY-MM-DD (UTC). Accepted with filter "all" or "resolved". A record's start is its scheduled_for, else the earlier of its started_at and created_at; records that started before since 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. On a vendor with no archive this tool reads, since filters only what its status feed returns. Where that feed is a recent window, a since earlier than the oldest record it returned gets that record's start date in the notice. A feed that carries its page's whole history (such as "redis-cloud" or "datadog") holds nothing older, so it gets that date only on an empty result whose until is earlier than it. Omit to read only the status API. | |
| until | No | 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. A record's start is its scheduled_for, else the earlier of its started_at and created_at; records that started after until 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. On a vendor with no archive this tool reads, until alone filters what its status feed returns. Where that feed is a recent window, the notice then gives the start date of the oldest record it returned. A feed that carries its page's whole history (such as "redis-cloud" or "datadog") gets that date only on an empty result whose until is earlier than it. | |
| filter | No | all: incidents plus scheduled maintenances. active: only incidents with status investigating/identified/monitoring. resolved: only fully resolved incidents. scheduled: only maintenance windows — upcoming and in-progress ones, plus completed ones on Atlassian Statuspage, Firehydrant ("redis-cloud"), and Datadog ("datadog", "datadog-eu1") vendors; Status.io vendors ("gitlab", "neon") list upcoming and in-progress windows only. 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. | all |
| offset | No | 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 | Yes | Vendor slug (e.g., "github", "aws") or raw Atlassian Statuspage base URL. Use devops_list_vendors to find slugs. | |
| full_updates | No | 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. |
| Name | Required | Description |
|---|---|---|
| cap | No | The limit that was applied: the requested limit, or 50 when a larger one was requested. Present only when truncated. |
| name | No | Display name of the vendor. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of incidents on this page: the limit, or fewer when the page stopped at the response size budget. Present only when truncated. |
| notice | No | Plain-language explanation of this result — a limit over 50 that was served as 50 (with the requested and effective values), a since older than the 24-month history-archive floor (with the date the archive was read back to), a since earlier than the oldest record a vendor feed that is a recent window with no history archive behind it returned, or an until without since on such a feed (with that record's start date), how to page onward, that the page stopped at the response size budget or left out an oversized incident's oldest updates (and the call that returns them all), why it came back empty (the vendor currently publishes nothing at all, a capped feed of a shared status page that returned nothing touching the vendor's components, a filter the backend cannot satisfy, an offset past the end, a since/until range or match terms that left everything out — naming the archive floor when the range reaches back past it, and where a feed that carries its page's whole history starts when the range ends before that), that the vendor feed capped the history (and whether since reaches past that cap), or how far the history archive was read when it stopped short of since or its floor. On a vendor that reads an umbrella status page with no components, such as "atlassian", its last sentence names the product slugs to check instead. Absent when the result needs no explanation. |
| vendor | No | Vendor slug or URL as provided. |
| incidents | No | Matching incidents. |
| truncated | No | True when more incidents matched than this page returned — because of limit, or because the page stopped at the response size budget. Absent when this page reached the end of the matches. |
| nextOffset | No | The offset to pass on the next call to continue from where this page stopped, already computed as offset + the number returned. Present only when truncated — its absence means this page reached the end of what the filter matched. |
| totalCount | No | Total incidents matching the filter, date range, and match, across all pages, before offset/limit windowing. Present only when the result was truncated. |
| statuspage_url | No | Status page base URL used. |
| total_returned | No | Number of incidents in the response. |
| upstreamCeiling | No | Maximum incidents the vendor's own status API serves in one fetch, present only when that ceiling was reached on this call. It bounds the history independently of limit and offset: incidents older than the oldest one returned cannot be fetched at any offset. On Atlassian Statuspage vendors, since reads past it from the page's history archive, except on a vendor that covers only part of a shared page, such as "sendgrid"; the notice says whether since reaches past it on this call. Absent when the vendor feed is unbounded, returned less than its ceiling, or since was set and the history archive was read back to it (or to its 24-month floor, when since is older). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld, yet the description adds substantial non-obvious behavior: filter-then-page ordering, a 64,000-byte per-surface budget, pages that can stop short of limit, oversized incidents keeping only newest updates with updates_omitted, upstreamCeiling marking unreachable older history, and self-explaining notices on empty results. These are exactly the traits an agent needs before trusting totals or paging.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is correctly front-loaded in sentence one, but the remainder is a dense run-on covering archive quirks, per-vendor exceptions, and budget mechanics in a single block. Repeated vendor examples ("sendgrid", "redis-cloud", "datadog") and restated paging rules make it harder to scan than the small number of decisions it supports warrants.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and the description still covers every edge case an agent would otherwise trip on: truncation, capture ceilings, archive coverage, and empty-result explanation. Little is left to discover by trial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter descriptions are already exhaustive, so the baseline is 3. The prose still adds cross-parameter meaning the schema leaves implicit: the interaction of full_updates with limit 1 plus the returned offset, the 24-month archive ceiling on since, and until being inert for archive reads unless since is also set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource: fetch incident history and scheduled maintenance windows for a named vendor, including full timelines, affected components, and resolutions. An agent can distinguish it from devops_status_check (current state) and devops_list_vendors (slug discovery) without consulting any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete when-to-use framing — active incidents before a deploy, resolved history for postmortem, maintenance windows for planned work — which maps directly onto the filter enum values. It never names a sibling tool as the better alternative for any case (e.g. checking live status), so routing is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Substring search against vendor slug and display name. Case-insensitive; surrounding whitespace is ignored. E.g., "cloud", "auth", "slack". | |
| category | No | Filter to one category: cloud, cdn-edge, dev-platform, data, comms, auth, monitoring, or ai. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| total | No | Total number of vendors returned. |
| notice | No | Why nothing matched and what to call next. Present only when vendors is empty. |
| vendors | No | Matching vendors from the built-in registry. |
| categories | No | All available category values for use in the category filter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true. The description adds useful behavioral context by identifying the source as the built-in registry and summarizing returned fields, though it does not discuss result size or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the operation and filters, followed by return information and usage guidance. Every sentence contributes useful information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a simple read-only list tool: it covers purpose, filtering, return fields, and when to use it. With an output schema present and full parameter description coverage, no critical agent-facing information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains the query substring behavior and the category enum in more detail than the description. The description only restates that filtering is optional and by category or name, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('List vendors') and narrows the scope to the built-in registry with optional category/name filtering. No sibling tool is a vendor-list operation, so the agent can distinguish this tool's role without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states when to use the tool: discovering the correct slug for other tools or checking available vendors before configuring a stack. It does not name an alternative or state when-not to use it, which keeps it below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, Datadog) and normalized to one shape. Returns per-vendor operational indicator as the vendor published it (none = no degradation reported, minor, major, critical, maintenance = scheduled window), degraded components, and active incidents; summary counts each vendor at the worse of its indicator and its worst open incident rated minor or worse. Use mode: "detailed" for component lists and maintenance windows, narrowed with component_filter, bounded by component_limit, and paged with component_offset. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | summary: indicator + degraded components + active incidents only. detailed: adds the component list and scheduled maintenance windows. | summary |
| vendors | Yes | 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 | No | Maximum components returned per vendor in detailed mode, at least 1. A value above 500 is reduced to 500, and notice says so; a longer list continues with component_offset. 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 | No | 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_offset and component_limit, so it reaches a specific component without paging, and an offset pages within the filtered list. A filter that matches nothing for a vendor is reported in notice. Ignored in summary mode. | |
| component_offset | No | Components to skip per vendor, after component_filter and before component_limit. Pass a vendor's next_component_offset to continue its list. An offset past a vendor's last component returns an empty list for it, and notice says so. Ignored in summary mode. |
| Name | Required | Description |
|---|---|---|
| cap | No | The per-vendor component_limit that was applied. Present only when truncated. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Components returned across all vendors. Present only when truncated. |
| notice | No | Plain-language explanation of what this call left out or adjusted, in this order: vendors past the first 20 (listed in deferred_vendors); a component_limit above 500 reduced to 500; in detailed mode, how many components lie past the returned page and how to reach them (this tool again with that vendor and its next_component_offset as component_offset, component_filter to target one, or component_limit to raise a cap below 500), which vendors component_offset ran past the end of, and which checked vendors component_filter matched no component of, with how many each publishes; and last, for a vendor whose entry reads an umbrella status page with no components (atlassian), the slugs of the entries reading its product pages. Present only when one of these applies. |
| results | No | Per-vendor status results for the vendors checked, in the same order as the input vendors list. |
| summary | No | Aggregate health counts across all checked vendors. Each vendor is rated by the worse of its indicator and its worst open incident rated minor or worse; an incident rated none or maintenance never raises the rating. Buckets partition the batch: operational + degraded + down + maintenance + unavailable = total. |
| truncated | No | True when at least one vendor has components past the returned page — those vendors carry next_component_offset. Absent otherwise, including on the last page of a list. |
| totalCount | No | Components matching component_filter across all vendors, before component_offset and the cap. Present only when truncated. |
| deferred_vendors | No | Entries past the first 20 in vendors, verbatim and in input order. They were not checked; resend them in another call. Empty when every entry was checked. |
| nextToolSuggestions | No | One devops_suggest_action call per vendor with an active problem — an indicator of minor, major, or critical, or an open incident of that impact even while the indicator reads none or maintenance; these are the vendors summary counts as degraded or down — with its arguments filled from that vendor's result. Vendors that could not be checked never appear. Empty when no checked vendor has an active problem. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnly/idempotent/openWorld), and the description adds substantial operational context beyond them: a 20-vendor per-call cap with deferred_vendors, per-vendor error isolation ("one bad entry never discards the rest"), cross-backend normalization, summary semantics (worse of indicator and worst incident), and the nextToolSuggestions side effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and batching guidance are front-loaded, and most sentences carry real information. The long inline vendor-backend parenthesis and some redundant restatement of schema-documented parameters add bulk without much payoff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch fan-out tool over external status APIs, the description covers the failure mode, the size cap, the refresh/resend workflow, and the interpretation of indicator values. An output schema exists, but the description still clarifies what the indicator levels mean, which is genuinely useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already explains mode, component_filter, component_limit, and component_offset in greater depth than the description does. The description only restates them in compressed form ("narrowed with component_filter, bounded by component_limit, and paged with component_offset"), so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Check the current health status for one or more vendors") and immediately pins the scope: registered vendor slugs or raw Statuspage URLs. It is clearly distinct from siblings like devops_check_certs, devops_check_dns, and devops_get_incidents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete routing within the tool ("Use mode: 'detailed' for component lists and maintenance windows") and a batching strategy ("pass a list to check your full stack in one call"). It does not explicitly contrast with devops_get_incidents, which also surfaces incidents, so an agent still has to infer that boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| vendor | Yes | 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 | No | Your own domain or service URL. When provided, nextToolSuggestions will be pre-filled with your domain for cert and DNS checks. | |
| incident_summary | No | Latest incident description or update body from devops_get_incidents. Paste the most recent update to get more targeted advice. | |
| vendor_indicator | No | 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 | No | 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. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| vendor | No | Vendor as provided. |
| guidance | No | Markdown playbook — immediate steps, diagnostic checks, mitigation options, and what to monitor for resolution. Tailored to the vendor category, reported severity, and affected components. |
| vendor_category | No | Detected category from registry (e.g., "cdn-edge", "auth"). Null for unrecognized vendors. |
| diagnostics_summary | No | Summary of input context used to generate the playbook. |
| nextToolSuggestions | No | Recommended follow-up calls with arguments already populated. Execute these in sequence to gather diagnostic data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, closed-world behavior, so the bar is lower. The description adds genuine context: guidance is synthesized from built-in incident knowledge plus the caller's context, and the output is a playbook with pre-filled follow-up calls. It stops short of noting any limits or caveats on that generated guidance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the verb and deliverable, then the synthesis mechanism, then the trigger. Every sentence carries information and none is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description needn't enumerate return values. It covers purpose, trigger conditions, input tailoring, and behavioral nature — everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the per-parameter descriptions (vendor slug fallback, your_domain pre-fill, indicator enum, component grouping) are richer than anything the prose adds. Baseline 3 is appropriate since the schema carries the parameter burden; the description only alludes to 'provided context'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (return) and resource (incident-response playbook), plus distinguishing detail: pre-filled follow-up tool calls tailored to vendor degradation. It names the sibling tools that surface the problem, so an agent can tell it apart from devops_status_check and devops_get_incidents without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to invoke it (after devops_status_check or devops_get_incidents surfaces a problem) and the goal (determine what to investigate next). Clear context, but no explicit exclusions or counter-indications for when a different sibling would be preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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").
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | summary: indicator + degraded components + active incidents. detailed: adds component lists and maintenance windows. | summary |
| vendors | No | 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 | No | 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. | default |
| component_limit | No | 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 | No | 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 reaches a specific component the cap would otherwise omit; a capped vendor's full list continues in devops_status_check from its next_component_offset. A filter that matches nothing for a vendor is reported in notice. Ignored in summary mode. |
| Name | Required | Description |
|---|---|---|
| cap | No | The per-vendor component_limit that was applied. Present only when truncated. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Components returned across the stack. Present only when truncated. |
| health | No | Aggregate health rollup over each checked vendor's rating — the worse of its indicator and its worst open incident rated minor or worse — taking the worst rung that applies: major_outage = a vendor rated critical, partial_outage = a vendor rated major, degraded = a vendor rated minor, unknown = at least one vendor could not be checked (unresolvable entry, blocked target, or failed fetch) and none rated worse, maintenance = a vendor in a scheduled window and nothing worse, all_operational = every vendor checked and rated none. Never all_operational when any vendor errored, is in a window, or has an open incident rated minor or worse. |
| notice | No | Plain-language explanation of what this call left out or adjusted, in this order: vendors past the first 20 (listed in deferred_vendors), and for a saved stack how to sweep every one; a component_limit above 500 reduced to 500; in detailed mode, how many components the cap omitted and how to reach them (devops_status_check with that vendor and its next_component_offset as component_offset, component_filter to target one, or component_limit to raise a cap below 500), and which checked vendors component_filter matched no component of, with how many each publishes; and last, for a vendor whose entry reads an umbrella status page with no components (atlassian), the slugs of the entries reading its product pages. Present only when one of these applies. |
| summary | No | Aggregate health counts across all checked vendors. Each vendor is rated by the worse of its indicator and its worst open incident rated minor or worse; an incident rated none or maintenance never raises the rating. Buckets partition the stack: operational + degraded + down + maintenance + unavailable = total. |
| vendors | No | Per-vendor status results for the vendors checked, in stack order. |
| truncated | No | True when at least one vendor's component list was capped at component_limit — those vendors carry next_component_offset. Absent when nothing was capped. |
| checked_at | No | ISO 8601 UTC timestamp of this check. |
| stack_name | No | Name of the stack checked. |
| totalCount | No | Components matching component_filter across the stack before the cap. Present only when truncated. |
| omitted_vendors | No | Entries that could not be resolved or whose URL was blocked; they still appear in vendors[] with an error. A call that saved the stack left them out of the write; a call that reused a saved stack leaves them in it until you re-provide the vendors list. Empty when every entry resolved. |
| stack_persisted | No | True when the vendor list was saved on this call. Only the vendors that resolved are saved — see omitted_vendors. Always false on a deployment that does not authenticate callers, which saves no stacks (persistence_notice says so). |
| deferred_vendors | No | Entries past the first 20, verbatim and in order, that were not checked on this call: the rest of a passed vendors list on a deployment that saves no stacks, or of a saved stack holding more than 20. Resend them in another call. Empty when every entry was checked. |
| persistence_notice | No | Present when this deployment saves no stacks because callers are not authenticated: nothing was saved, and vendors must be passed on every call. |
| nextToolSuggestions | No | One devops_suggest_action call per vendor with an active problem — an indicator of minor, major, or critical, or an open incident of that impact even while the indicator reads none or maintenance; these are the vendors summary counts as degraded or down — with its arguments filled from that vendor's result. Vendors that could not be checked never appear. Empty when no checked vendor has an active problem. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond annotations by disclosing persistence semantics (saved per caller, or per local server process), the no-auth deployment case where nothing is saved and vendors is required, the 20-vendor save/check cap, and failure handling (unresolvable vendors reported in their own row and excluded from the saved stack). It also flags that nextToolSuggestions carries pre-filled devops_suggest_action calls, which is non-obvious behavior an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads purpose and the core stateful mechanic, then layers in limits, failure behavior, and suggested follow-up in a logical order. It is dense but every clause carries operational information; a couple of sentences (e.g., the multiple-stack example) are mildly redundant with the schema's stack_name description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a stateful, open-world tool with five optional params, the description covers persistence scope, caps, degraded-vendor handling, and response shape ('aggregate rollup plus per-vendor detail'), even though an output schema exists. Nothing essential for a correct first call is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds cross-call meaning the schema alone doesn't convey — that omitting vendors reuses a saved list, that the list is re-saved on each supply, and that the 20-cap behaves differently on non-authenticating deployments. Mode, component_limit, and component_filter are left to their already-detailed schema entries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource ('Check the health of a named vendor stack') and immediately defines the domain object (a saved vendor list representing infrastructure dependencies). This distinguishes it clearly from siblings like devops_status_check and devops_check_dns, which operate on individual vendor/record checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete usage contexts ('morning status checks or pre-deploy sweeps') and explains the stateful first-call vs subsequent-call pattern, plus multiple-stack naming. It does not explicitly say when to prefer devops_status_check or devops_list_vendors over this tool, so routing guidance is positive-only rather than comparative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
devops_get_incidents7 fields changedInput schema / properties / filter / descriptionPrevious value: -"all: incidents plus scheduled maintenances. active: only incidents with status investigating/identified/monitoring. resolved: only fully resolved incidents. scheduled: only maintenance windows — upcoming and in-progress ones, plus completed ones on Atlassian Statuspage and Firehydrant (\"redis-cloud\") vendors; Status.io vendors (\"gitlab\", \"neon\") list upcoming and in-progress windows only. 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."New value: +"all: incidents plus scheduled maintenances. active: only incidents with status investigating/identified/monitoring. resolved: only fully resolved incidents. scheduled: only maintenance windows — upcoming and in-progress ones, plus completed ones on Atlassian Statuspage, Firehydrant (\"redis-cloud\"), and Datadog (\"datadog\", \"datadog-eu1\") vendors; Status.io vendors (\"gitlab\", \"neon\") list upcoming and in-progress windows only. 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."Input schema / properties / match / descriptionPrevious value: -"Words to look for in each incident's title, its affected component names, and, on Google Cloud, its affected location names and IDs (\"us-central1\", \"iowa\"), 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, one of its component names, or one of its location names or IDs. 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."New value: +"Terms to look for, separated by spaces, in each incident's title, its affected component names, and, on Google Cloud and AWS, its affected location names and IDs (\"us-central1\", \"me-south-1\", \"bahrain\"), ignoring case. An incident is kept when every term appears in its title, one of its component names, or one of its location names or IDs, each term on its own. A one-word term matches all or part of a word. A term whose words are joined by punctuation (\"eu-central-1\", \"git-operations\", \"git/operations\") matches only where those words appear together, in that order, within one of those texts, anywhere in it: \"eu-central-1\" finds eu-central-1 but not me-central-1, and \"eu-west\" finds every eu-west region. 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."Input schema / properties / since / descriptionPrevious value: -"Earliest start date to include, as YYYY-MM-DD (UTC). Accepted with filter \"all\" or \"resolved\". A record's start is its scheduled_for, else the earlier of its started_at and created_at; records that started before since 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. On a vendor with no archive this tool reads, since filters only what its status feed returns, which on most is a recent window: when since is earlier than the oldest record that feed returned, the notice gives that record's start date. Omit to read only the status API."New value: +"Earliest start date to include, as YYYY-MM-DD (UTC). Accepted with filter \"all\" or \"resolved\". A record's start is its scheduled_for, else the earlier of its started_at and created_at; records that started before since 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. On a vendor with no archive this tool reads, since filters only what its status feed returns. Where that feed is a recent window, a since earlier than the oldest record it returned gets that record's start date in the notice. A feed that carries its page's whole history (such as \"redis-cloud\" or \"datadog\") holds nothing older, so it gets that date only on an empty result whose until is earlier than it. Omit to read only the status API."Input schema / properties / until / descriptionPrevious value: -"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. A record's start is its scheduled_for, else the earlier of its started_at and created_at; records that started after until 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."New value: +"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. A record's start is its scheduled_for, else the earlier of its started_at and created_at; records that started after until 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. On a vendor with no archive this tool reads, until alone filters what its status feed returns. Where that feed is a recent window, the notice then gives the start date of the oldest record it returned. A feed that carries its page's whole history (such as \"redis-cloud\" or \"datadog\") gets that date only on an empty result whose until is earlier than it."Output schema / properties / incidents / items / properties / affected_locations / descriptionPrevious value: -"Google Cloud regions and multi-regions the incident lists, currently affected first; absent when it lists none."New value: +"Regions the incident lists, currently affected first: on Google Cloud its regions and multi-regions, on AWS the one region its event names (\"global\" for a global service); absent when it lists none."Output schema / properties / notice / descriptionPrevious value: -"Plain-language explanation of this result — a limit over 50 that was served as 50 (with the requested and effective values), a since older than the 24-month history-archive floor (with the date the archive was read back to), a since earlier than the oldest record a vendor feed with no history archive returned (with that record's start date), how to page onward, that the page stopped at the response size budget or left out an oversized incident's oldest updates (and the call that returns them all), why it came back empty (the vendor currently publishes nothing at all, a filter the backend cannot satisfy, an offset past the end, a since/until range or match words that left everything out — naming the archive floor when the range starts before it), that the vendor feed capped the history, or how far the history archive was read when it stopped short of since or its floor. On a vendor that reads an umbrella status page with no components, such as \"atlassian\", its last sentence names the product slugs to check instead. Absent when the result needs no explanation."New value: +"Plain-language explanation of this result — a limit over 50 that was served as 50 (with the requested and effective values), a since older than the 24-month history-archive floor (with the date the archive was read back to), a since earlier than the oldest record a vendor feed that is a recent window with no history archive behind it returned, or an until without since on such a feed (with that record's start date), how to page onward, that the page stopped at the response size budget or left out an oversized incident's oldest updates (and the call that returns them all), why it came back empty (the vendor currently publishes nothing at all, a capped feed of a shared status page that returned nothing touching the vendor's components, a filter the backend cannot satisfy, an offset past the end, a since/until range or match terms that left everything out — naming the archive floor when the range reaches back past it, and where a feed that carries its page's whole history starts when the range ends before that), that the vendor feed capped the history (and whether since reaches past that cap), or how far the history archive was read when it stopped short of since or its floor. On a vendor that reads an umbrella status page with no components, such as \"atlassian\", its last sentence names the product slugs to check instead. Absent when the result needs no explanation."Output schema / properties / upstreamCeiling / descriptionPrevious value: -"Maximum incidents the vendor's own status API serves in one fetch, present only when that ceiling was reached on this call. It bounds the history independently of limit and offset: incidents older than the oldest one returned cannot be fetched at any offset. On Atlassian Statuspage vendors, since reads past it from the page's history archive, except on a vendor that covers only part of a shared page, such as \"sendgrid\". Absent when the vendor feed is unbounded, returned less than its ceiling, or since was set and the history archive was read back to it (or to its 24-month floor, when since is older)."New value: +"Maximum incidents the vendor's own status API serves in one fetch, present only when that ceiling was reached on this call. It bounds the history independently of limit and offset: incidents older than the oldest one returned cannot be fetched at any offset. On Atlassian Statuspage vendors, since reads past it from the page's history archive, except on a vendor that covers only part of a shared page, such as \"sendgrid\"; the notice says whether since reaches past it on this call. Absent when the vendor feed is unbounded, returned less than its ceiling, or since was set and the history archive was read back to it (or to its 24-month floor, when since is older)."devops_list_vendors1 field changedOutput schema / properties / vendors / items / properties / statuspage_url / descriptionPrevious value: -"Status page base URL — the Statuspage API base for Statuspage-backed vendors, the public status page URL for adapter-backed vendors (aws, gcp, azure, azure-devops, gitlab, slack, neon, redis-cloud)."New value: +"Status page base URL — the Statuspage API base for Statuspage-backed vendors, the public status page URL for adapter-backed vendors (aws, gcp, azure, azure-devops, gitlab, slack, neon, redis-cloud, and datadog with its datadog-* site entries)."devops_check_certs1 field changedOutput schema / properties / results / items / properties / cert / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "authorization_error": {
- "description": "OpenSSL chain-verification code when the certificate chain does not validate against the system trust store, or null when it validates. Common values: \"DEPTH_ZERO_SELF_SIGNED_CERT\" (self-signed leaf), \"SELF_SIGNED_CERT_IN_CHAIN\" / \"UNABLE_TO_VERIFY_LEAF_SIGNATURE\" (issuing root not trusted), \"CERT_HAS_EXPIRED\" (also reported in \"days_until_expiry\"). This is the authoritative chain-trust signal — the issuer and subject fields alone cannot detect an untrusted root.",
- "type": [
- "string",
- "null"
- ]
- },
- "chain_depth": {
- "anyOf": [
- {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- {
- "type": "null"
- }
- ],
- "description": "Number of certificates the server sent, counting the leaf. Null when the runtime does not expose the issuer chain — read \"chain_depth_unavailable_reason\" in that case. Not a self-signed indicator: use \"authorization_error\" for that."
- },
- "chain_depth_unavailable_reason": {
- "description": "Why \"chain_depth\" is null, or null when a depth was measured. Absence of a depth is a runtime limitation, not a finding about the certificate.",
- "type": [
- "string",
- "null"
- ]
- },
- "days_until_expiry": {
- "description": "Days remaining until certificate expiry. Negative = already expired.",
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- "hostname_verification_error": {
- "description": "Node's hostname-verification message when the requested domain is not covered by the certificate's CN or SANs (e.g. \"Hostname/IP does not match certificate's altnames: …\"), or null when the hostname is covered. A non-null value means ordinary clients reject this certificate for this hostname; compare against the \"san\" list to see what it does cover.",
- "type": [
- "string",
- "null"
- ]
- },
- "issuer": {
- "description": "Issuer common name.",
- "type": "string"
- },
- "san": {
- "description": "Subject Alternative Names covered by this certificate.",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "serial": {
- "description": "Certificate serial number.",
- "type": "string"
- },
- "subject": {
- "description": "Certificate subject CN.",
- "type": "string"
- },
- "valid_from": {
- "description": "ISO 8601 UTC timestamp of certificate validity start.",
- "type": "string"
- },
- "valid_until": {
- "description": "ISO 8601 UTC timestamp of certificate expiry.",
- "type": "string"
- }
- },
- "required": [
- "subject",
- "san",
- "issuer",
- "valid_from",
- "valid_until",
- "days_until_expiry",
- "chain_depth",
- "chain_depth_unavailable_reason",
- "hostname_verification_error",
- "authorization_error",
- "serial"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "authorization_error": {
+ "description": "OpenSSL chain-verification code when the certificate chain does not validate against the system trust store, or null when it validates. Common values: \"DEPTH_ZERO_SELF_SIGNED_CERT\" (self-signed leaf), \"SELF_SIGNED_CERT_IN_CHAIN\" / \"UNABLE_TO_VERIFY_LEAF_SIGNATURE\" (issuing root not trusted), \"CERT_HAS_EXPIRED\" (also reported in \"days_until_expiry\"). This is the authoritative chain-trust signal — the issuer and subject fields alone cannot detect an untrusted root.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "chain_depth": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Length of the certificate chain this runtime assembled from the leaf, counting the leaf: the certificates the server sent on the leaf's issuer path, then issuers from the runtime's own trust store, up to a self-signed certificate or one whose issuer was not found. It can include a root the server never sent, so it can differ from the number of certificates the server sent, and between runtimes. Null when no issuer for the leaf was found — read \"chain_depth_unavailable_reason\". Not a self-signed indicator or a trust verdict: use \"authorization_error\" for those."
+ },
+ "chain_depth_unavailable_reason": {
+ "description": "Why \"chain_depth\" is null, or null when a depth was measured. A null depth means no issuer for the leaf was found among the certificates the server sent or in the trust store, as when a server sends its leaf without the certificate that issued it.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "days_until_expiry": {
+ "description": "Days remaining until certificate expiry. Negative = already expired.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "hostname_verification_error": {
+ "description": "Node's hostname-verification message when the requested domain is not covered by the certificate's CN or SANs (e.g. \"Hostname/IP does not match certificate's altnames: …\"), or null when the hostname is covered. A non-null value means ordinary clients reject this certificate for this hostname; compare against the \"san\" list to see what it does cover.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "issuer": {
+ "description": "Issuer common name.",
+ "type": "string"
+ },
+ "san": {
+ "description": "Subject Alternative Names covered by this certificate.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "serial": {
+ "description": "Certificate serial number.",
+ "type": "string"
+ },
+ "subject": {
+ "description": "Certificate subject CN.",
+ "type": "string"
+ },
+ "valid_from": {
+ "description": "ISO 8601 UTC timestamp of certificate validity start.",
+ "type": "string"
+ },
+ "valid_until": {
+ "description": "ISO 8601 UTC timestamp of certificate expiry.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "subject",
+ "san",
+ "issuer",
+ "valid_from",
+ "valid_until",
+ "days_until_expiry",
+ "chain_depth",
+ "chain_depth_unavailable_reason",
+ "hostname_verification_error",
+ "authorization_error",
+ "serial"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]devops_check_dns1 field changedOutput schema / properties / results / items / properties / error / descriptionPrevious value: -"Set only when the domain could not be queried at all. Either it was rejected before any query — the entry is not a domain name (the message names the entry and the accepted shapes), or it is a private, loopback, or cloud-metadata target — and \"resolver_results\" is empty, or every resolver failed and none returned records, in which case each failing resolver is named with its own outcome (\"8.8.8.8: SERVFAIL on A; 1.1.1.1: NXDOMAIN on A\") so a split result stays visible. Null when at least one resolver answered; per-resolver failures are still in \"resolver_results\" and \"flags\"."New value: +"Set only when the domain could not be queried at all: either the entry is not a domain name — rejected before any query, so \"resolver_results\" is empty, and the message names the entry and the accepted shapes — or every resolver failed and none returned records, in which case each failing resolver is named with its own outcome (\"8.8.8.8: SERVFAIL on A; 1.1.1.1: NXDOMAIN on A\") so a split result stays visible. Null when at least one resolver answered; per-resolver failures are still in \"resolver_results\" and \"flags\"."devops_get_incidents7 fields changedInput schema / properties / filter / descriptionPrevious value: -"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."New value: +"all: incidents plus scheduled maintenances. active: only incidents with status investigating/identified/monitoring. resolved: only fully resolved incidents. scheduled: only maintenance windows — upcoming and in-progress ones, plus completed ones on Atlassian Statuspage and Firehydrant (\"redis-cloud\") vendors; Status.io vendors (\"gitlab\", \"neon\") list upcoming and in-progress windows only. 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."Input schema / properties / match / descriptionPrevious value: -"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."New value: +"Words to look for in each incident's title, its affected component names, and, on Google Cloud, its affected location names and IDs (\"us-central1\", \"iowa\"), 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, one of its component names, or one of its location names or IDs. 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."Input schema / properties / since / descriptionPrevious value: -"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."New value: +"Earliest start date to include, as YYYY-MM-DD (UTC). Accepted with filter \"all\" or \"resolved\". A record's start is its scheduled_for, else the earlier of its started_at and created_at; records that started before since 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. On a vendor with no archive this tool reads, since filters only what its status feed returns, which on most is a recent window: when since is earlier than the oldest record that feed returned, the notice gives that record's start date. Omit to read only the status API."Input schema / properties / until / descriptionPrevious value: -"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."New value: +"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. A record's start is its scheduled_for, else the earlier of its started_at and created_at; records that started after until 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."Output schema / properties / incidents / items / properties / affected_locationsAdded value: +{
+ "description": "Google Cloud regions and multi-regions the incident lists, currently affected first; absent when it lists none.",
+ "items": {
+ "additionalProperties": false,
+ "description": "A location the incident lists.",
+ "properties": {
+ "current": {
+ "description": "True while the incident still affects this location; false once it has stopped affecting it.",
+ "type": "boolean"
+ },
+ "id": {
+ "description": "Provider location ID, e.g. \"us-central1\".",
+ "type": "string"
+ },
+ "name": {
+ "description": "Provider location name, e.g. \"Iowa (us-central1)\".",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "current"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / incidents / items / properties / scheduled_until / descriptionPrevious value: -"Present for scheduled maintenances — ISO 8601 end time with the vendor's UTC offset."New value: +"Present for scheduled maintenances — ISO 8601 end time with the vendor's UTC offset, or null when the vendor's feed publishes no planned end."Output schema / properties / notice / descriptionPrevious value: -"Plain-language explanation of this result — a limit over 50 that was served as 50 (with the requested and effective values), a since older than the 24-month history-archive floor (with the date the archive was read back to), how to page onward, that the page stopped at the response size budget or left out an oversized incident's oldest updates (and the call that returns them all), why it came back empty (the vendor currently publishes nothing at all, a filter the backend cannot satisfy, an offset past the end, a since/until range or match words that left everything out — naming the archive floor when the range starts before it), that the vendor feed capped the history, or how far the history archive was read when it stopped short of since or its floor. Absent when the result needs no explanation."New value: +"Plain-language explanation of this result — a limit over 50 that was served as 50 (with the requested and effective values), a since older than the 24-month history-archive floor (with the date the archive was read back to), a since earlier than the oldest record a vendor feed with no history archive returned (with that record's start date), how to page onward, that the page stopped at the response size budget or left out an oversized incident's oldest updates (and the call that returns them all), why it came back empty (the vendor currently publishes nothing at all, a filter the backend cannot satisfy, an offset past the end, a since/until range or match words that left everything out — naming the archive floor when the range starts before it), that the vendor feed capped the history, or how far the history archive was read when it stopped short of since or its floor. On a vendor that reads an umbrella status page with no components, such as \"atlassian\", its last sentence names the product slugs to check instead. Absent when the result needs no explanation."devops_status_check20 fields changedInput schema / properties / component_filter / descriptionPrevious value: -"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."New value: +"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_offset and component_limit, so it reaches a specific component without paging, and an offset pages within the filtered list. A filter that matches nothing for a vendor is reported in notice. Ignored in summary mode."Input schema / properties / component_limit / descriptionPrevious value: -"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."New value: +"Maximum components returned per vendor in detailed mode, at least 1. A value above 500 is reduced to 500, and notice says so; a longer list continues with component_offset. 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."Input schema / properties / component_offsetAdded value: +{
+ "default": 0,
+ "description": "Components to skip per vendor, after component_filter and before component_limit. Pass a vendor's next_component_offset to continue its list. An offset past a vendor's last component returns an empty list for it, and notice says so. Ignored in summary mode.",
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+}Output schema / properties / nextToolSuggestions / descriptionPrevious value: -"One devops_suggest_action call per vendor with an active problem — an indicator of minor, major, or critical, or an open incident of that impact even while the indicator reads none or maintenance — with its arguments filled from that vendor's result. Vendors that could not be checked never appear. Empty when no checked vendor has an active problem."New value: +"One devops_suggest_action call per vendor with an active problem — an indicator of minor, major, or critical, or an open incident of that impact even while the indicator reads none or maintenance; these are the vendors summary counts as degraded or down — with its arguments filled from that vendor's result. Vendors that could not be checked never appear. Empty when no checked vendor has an active problem."Output schema / properties / notice / descriptionPrevious value: -"Plain-language explanation of what this call left out or adjusted: vendors past the first 20 (listed in deferred_vendors), a component_limit above 500 reduced to 500, and in detailed mode how many components the cap omitted and how to reach them (component_filter to target one, or component_limit to raise a cap below 500), and which checked vendors component_filter matched no component of, with how many each publishes. Present only when one of these applies."New value: +"Plain-language explanation of what this call left out or adjusted, in this order: vendors past the first 20 (listed in deferred_vendors); a component_limit above 500 reduced to 500; in detailed mode, how many components lie past the returned page and how to reach them (this tool again with that vendor and its next_component_offset as component_offset, component_filter to target one, or component_limit to raise a cap below 500), which vendors component_offset ran past the end of, and which checked vendors component_filter matched no component of, with how many each publishes; and last, for a vendor whose entry reads an umbrella status page with no components (atlassian), the slugs of the entries reading its product pages. Present only when one of these applies."Output schema / properties / results / items / properties / all_components / descriptionPrevious value: -"Components including operational ones, capped at component_limit per vendor and narrowed by component_filter (matched against name and group) when given. Present in detailed mode only."New value: +"Components including operational ones, narrowed by component_filter (matched against name and group) when given, starting at component_offset (devops_status_check only; the first component otherwise), and at most component_limit per vendor. Present in detailed mode only."Output schema / properties / results / items / properties / all_components_total / descriptionPrevious value: -"Components matching component_filter for this vendor before the component_limit cap. Larger than the length of all_components when this vendor was capped. Present in detailed mode only."New value: +"Components matching component_filter for this vendor, before component_offset and component_limit — the length of the whole list all_components is a page of. Present in detailed mode only."Output schema / properties / results / items / properties / cached / descriptionPrevious value: -"True when this result was served from the 60s in-memory cache."New value: +"True when this result was served from the in-memory status cache, shared across callers (60 s TTL by default), so its data can be up to that TTL older than checked_at."Output schema / properties / results / items / properties / checked_at / descriptionPrevious value: -"ISO 8601 UTC timestamp of this check."New value: +"ISO 8601 UTC timestamp of this check — when this result was built, not when the status data was fetched; see cached."Output schema / properties / results / items / properties / indicator / descriptionPrevious value: -"Overall health indicator: none = all clear, minor = some degradation, major = significant outage, critical = complete outage, maintenance = scheduled window in progress, planned rather than a fault."New value: +"Overall health indicator, as the vendor published it: none = no degradation reported, minor = some degradation, major = significant outage, critical = complete outage, maintenance = scheduled window in progress, planned rather than a fault. A page can rate it from component statuses alone, so it can read none or maintenance while active_incidents lists an open incident rated minor or worse; summary, and devops_watch_stack's health, rate the vendor by the worse of the two."Output schema / properties / results / items / properties / next_component_offsetAdded value: +{
+ "description": "Where this vendor's component list continues. Present in detailed mode only, and only when components remain past the returned page: pass it as component_offset to devops_status_check, with this vendor, mode \"detailed\", and the same component_filter. Absent on the last page.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+}Output schema / properties / results / items / properties / scheduled_maintenances / items / properties / scheduled_until / descriptionPrevious value: -"ISO 8601 end time, with the vendor's UTC offset."New value: +"ISO 8601 end time, with the vendor's UTC offset, or null when the vendor's feed publishes no planned end."Output schema / properties / results / items / properties / scheduled_maintenances / items / properties / scheduled_until / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / summary / descriptionPrevious value: -"Aggregate health counts across all checked vendors. Buckets partition the batch: operational + degraded + down + maintenance + unavailable = total."New value: +"Aggregate health counts across all checked vendors. Each vendor is rated by the worse of its indicator and its worst open incident rated minor or worse; an incident rated none or maintenance never raises the rating. Buckets partition the batch: operational + degraded + down + maintenance + unavailable = total."Output schema / properties / summary / properties / degraded / descriptionPrevious value: -"Vendors with indicator = minor or major."New value: +"Vendors rated minor or major."Output schema / properties / summary / properties / down / descriptionPrevious value: -"Vendors with indicator = critical."New value: +"Vendors rated critical."Output schema / properties / summary / properties / maintenance / descriptionPrevious value: -"Vendors with indicator = maintenance — in a scheduled window the vendor published. Counted apart from degraded and down, which are faults."New value: +"Vendors rated maintenance — in a scheduled window the vendor published, with no open incident rated minor or worse. Counted apart from degraded and down, which are faults."Output schema / properties / summary / properties / operational / descriptionPrevious value: -"Vendors with indicator = none and no error."New value: +"Vendors rated none — indicator none and no open incident rated minor or worse — and not errored."Output schema / properties / totalCount / descriptionPrevious value: -"Components matching component_filter across all vendors before the cap. Present only when truncated."New value: +"Components matching component_filter across all vendors, before component_offset and the cap. Present only when truncated."Output schema / properties / truncated / descriptionPrevious value: -"True when at least one vendor's component list was capped at component_limit. Absent when nothing was capped."New value: +"True when at least one vendor has components past the returned page — those vendors carry next_component_offset. Absent otherwise, including on the last page of a list."devops_watch_stack18 fields changedInput schema / properties / component_filter / descriptionPrevious value: -"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."New value: +"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 reaches a specific component the cap would otherwise omit; a capped vendor's full list continues in devops_status_check from its next_component_offset. A filter that matches nothing for a vendor is reported in notice. Ignored in summary mode."Output schema / properties / health / descriptionPrevious value: -"Aggregate health rollup: all_operational = everything clear, maintenance = at least one vendor in a scheduled window and nothing worse open, degraded = at least one minor issue, partial_outage = at least one major issue, major_outage = at least one critical outage, unknown = at least one vendor could not be checked (unresolvable entry, blocked target, or failed fetch) and no checked vendor reported a worse issue. Never all_operational when any vendor errored or is in a window."New value: +"Aggregate health rollup over each checked vendor's rating — the worse of its indicator and its worst open incident rated minor or worse — taking the worst rung that applies: major_outage = a vendor rated critical, partial_outage = a vendor rated major, degraded = a vendor rated minor, unknown = at least one vendor could not be checked (unresolvable entry, blocked target, or failed fetch) and none rated worse, maintenance = a vendor in a scheduled window and nothing worse, all_operational = every vendor checked and rated none. Never all_operational when any vendor errored, is in a window, or has an open incident rated minor or worse."Output schema / properties / nextToolSuggestions / descriptionPrevious value: -"One devops_suggest_action call per vendor with an active problem — an indicator of minor, major, or critical, or an open incident of that impact even while the indicator reads none or maintenance — with its arguments filled from that vendor's result. Vendors that could not be checked never appear. Empty when no checked vendor has an active problem."New value: +"One devops_suggest_action call per vendor with an active problem — an indicator of minor, major, or critical, or an open incident of that impact even while the indicator reads none or maintenance; these are the vendors summary counts as degraded or down — with its arguments filled from that vendor's result. Vendors that could not be checked never appear. Empty when no checked vendor has an active problem."Output schema / properties / notice / descriptionPrevious value: -"Plain-language explanation of what this call left out or adjusted: vendors past the first 20 (listed in deferred_vendors), a component_limit above 500 reduced to 500, and in detailed mode how many components the cap omitted and how to reach them (component_filter to target one, or component_limit to raise a cap below 500), and which checked vendors component_filter matched no component of, with how many each publishes. Present only when one of these applies."New value: +"Plain-language explanation of what this call left out or adjusted, in this order: vendors past the first 20 (listed in deferred_vendors), and for a saved stack how to sweep every one; a component_limit above 500 reduced to 500; in detailed mode, how many components the cap omitted and how to reach them (devops_status_check with that vendor and its next_component_offset as component_offset, component_filter to target one, or component_limit to raise a cap below 500), and which checked vendors component_filter matched no component of, with how many each publishes; and last, for a vendor whose entry reads an umbrella status page with no components (atlassian), the slugs of the entries reading its product pages. Present only when one of these applies."Output schema / properties / summary / descriptionPrevious value: -"Aggregate health counts across all checked vendors. Buckets partition the stack: operational + degraded + down + maintenance + unavailable = total."New value: +"Aggregate health counts across all checked vendors. Each vendor is rated by the worse of its indicator and its worst open incident rated minor or worse; an incident rated none or maintenance never raises the rating. Buckets partition the stack: operational + degraded + down + maintenance + unavailable = total."Output schema / properties / summary / properties / degraded / descriptionPrevious value: -"Vendors with indicator = minor or major."New value: +"Vendors rated minor or major."Output schema / properties / summary / properties / down / descriptionPrevious value: -"Vendors with indicator = critical."New value: +"Vendors rated critical."Output schema / properties / summary / properties / maintenance / descriptionPrevious value: -"Vendors with indicator = maintenance — in a scheduled window the vendor published. Counted apart from degraded and down, which are faults."New value: +"Vendors rated maintenance — in a scheduled window the vendor published, with no open incident rated minor or worse. Counted apart from degraded and down, which are faults."Output schema / properties / summary / properties / operational / descriptionPrevious value: -"Vendors with indicator = none and no error."New value: +"Vendors rated none — indicator none and no open incident rated minor or worse — and not errored."Output schema / properties / truncated / descriptionPrevious value: -"True when at least one vendor's component list was capped at component_limit. Absent when nothing was capped."New value: +"True when at least one vendor's component list was capped at component_limit — those vendors carry next_component_offset. Absent when nothing was capped."Output schema / properties / vendors / items / properties / all_components / descriptionPrevious value: -"Components including operational ones, capped at component_limit per vendor and narrowed by component_filter (matched against name and group) when given. Present in detailed mode only."New value: +"Components including operational ones, narrowed by component_filter (matched against name and group) when given, starting at component_offset (devops_status_check only; the first component otherwise), and at most component_limit per vendor. Present in detailed mode only."Output schema / properties / vendors / items / properties / all_components_total / descriptionPrevious value: -"Components matching component_filter for this vendor before the component_limit cap. Larger than the length of all_components when this vendor was capped. Present in detailed mode only."New value: +"Components matching component_filter for this vendor, before component_offset and component_limit — the length of the whole list all_components is a page of. Present in detailed mode only."Output schema / properties / vendors / items / properties / cached / descriptionPrevious value: -"True when this result was served from the 60s in-memory cache."New value: +"True when this result was served from the in-memory status cache, shared across callers (60 s TTL by default), so its data can be up to that TTL older than checked_at."Output schema / properties / vendors / items / properties / checked_at / descriptionPrevious value: -"ISO 8601 UTC timestamp of this check."New value: +"ISO 8601 UTC timestamp of this check — when this result was built, not when the status data was fetched; see cached."Output schema / properties / vendors / items / properties / indicator / descriptionPrevious value: -"Overall health indicator: none = all clear, minor = some degradation, major = significant outage, critical = complete outage, maintenance = scheduled window in progress, planned rather than a fault."New value: +"Overall health indicator, as the vendor published it: none = no degradation reported, minor = some degradation, major = significant outage, critical = complete outage, maintenance = scheduled window in progress, planned rather than a fault. A page can rate it from component statuses alone, so it can read none or maintenance while active_incidents lists an open incident rated minor or worse; summary, and devops_watch_stack's health, rate the vendor by the worse of the two."Output schema / properties / vendors / items / properties / next_component_offsetAdded value: +{
+ "description": "Where this vendor's component list continues. Present in detailed mode only, and only when components remain past the returned page: pass it as component_offset to devops_status_check, with this vendor, mode \"detailed\", and the same component_filter. Absent on the last page.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+}Output schema / properties / vendors / items / properties / scheduled_maintenances / items / properties / scheduled_until / descriptionPrevious value: -"ISO 8601 end time, with the vendor's UTC offset."New value: +"ISO 8601 end time, with the vendor's UTC offset, or null when the vendor's feed publishes no planned end."Output schema / properties / vendors / items / properties / scheduled_maintenances / items / properties / scheduled_until / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]devops_check_certs16 fields changedInput schema / properties / domains / descriptionPrevious value: -"Domains to inspect. Do not include \"https://\" — pass the bare hostname. Up to 10 per call."New value: +"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."Input schema / properties / domains / items / descriptionPrevious value: -"Domain name without protocol (e.g., \"api.github.com\", \"example.com\")."New value: +"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."Input schema / properties / domains / maxItemsPrevious value: -10New value: +100Input schema / properties / port / descriptionPrevious value: -"TLS port. Defaults to 443. Use 8443 or custom ports for non-standard HTTPS endpoints."New value: +"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."Input schema / properties / timeout_ms / descriptionPrevious value: -"Connection timeout per domain in milliseconds. Defaults to the DEVOPS_STATUS_CERT_TIMEOUT_MS env var (5000 when unset). Increase for slow or geographically distant endpoints."New value: +"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."Input schema / properties / timeout_ms / maximumPrevious value: -15000New value: +9007199254740991Output schema / anyOfPrevious value: -[
- {
- "not": {
- "required": [
- "error"
- ]
- },
- "required": [
- "results"
- ]
- },
- {
- "required": [
- "error"
- ]
- }
-]New value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "results",
+ "deferred_domains"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / deferred_domainsAdded value: +{
+ "description": "Host entries past the first 10, not inspected on this call, verbatim and in input order. Resend them in another call. Empty when every entry was inspected.",
+ "items": {
+ "description": "A submitted host entry, exactly as sent.",
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `invalid_domain`: A domain string contains a protocol prefix or invalid characters. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode."Output schema / properties / error / properties / data / properties / reason / examplesRemoved value: -[
- "invalid_domain"
-]Output schema / properties / noticeAdded value: +{
+ "description": "Present when the call was served at a bound: hosts past the per-call cap, named in deferred_domains, or a timeout_ms over 15000 that was served as 15000. Absent otherwise.",
+ "type": "string"
+}Output schema / properties / results / items / properties / domain / descriptionPrevious value: -"The domain that was inspected."New value: +"The host that was inspected, as read from the submitted entry (lowercase, ASCII, no scheme, port, or path; an IPv6 address without brackets). For an entry with no single host, the submitted string as given."Output schema / properties / results / items / properties / error / descriptionPrevious value: -"Why status is \"error\". Either no handshake completed — the domain was rejected as a private, loopback, or cloud-metadata target, a connection failure such as \"getaddrinfo ENOTFOUND …\", or \"Timed out after 5000ms\" — with cert and tls null and flags empty; or the handshake completed but the server presented no certificate, with cert null and the TLS session still reported in tls and flags. Null for every other status."New value: +"Why status is \"error\". Either no handshake completed — the entry has no single host (the message names the entry and the accepted shapes), the host was rejected as a private, loopback, or cloud-metadata target, a connection failure such as \"getaddrinfo ENOTFOUND …\" (for a server offering only TLS 1.0/1.1 that still refuses, the failure of the legacy-version attempt), or \"Timed out after 5000ms\" when timeout_ms ran out before a handshake completed — with cert and tls null and flags empty; or the handshake completed but the server presented no certificate, with cert null and the TLS session still reported in tls and flags. Null for every other status, including a completed handshake whose port never answered HTTP."Output schema / properties / results / items / properties / flags / descriptionPrevious value: -"Human-readable findings about the certificate and TLS session that were read: \"Expires in 12 days (warning)\", \"Certificate expired 40 days ago\", \"Hostname mismatch — the certificate does not cover api.example.com; clients will reject it\", \"Certificate chain not trusted (SELF_SIGNED_CERT_IN_CHAIN); clients will reject it\", \"Self-signed certificate\", \"Insecure TLS version in use: TLSv1.1\", \"HSTS present\" / \"HSTS not configured\". Empty when the connection never completed a handshake (rejected target, connection failure, or timeout) — the reason is in \"error\" only. A handshake that completed without a certificate keeps its TLS-session findings here alongside \"error\"."New value: +"Human-readable findings about the certificate and TLS session that were read: \"Expires in 12 days (warning)\", \"Certificate expired 40 days ago\", \"Hostname mismatch — the certificate does not cover api.example.com; clients will reject it\", \"Certificate chain not trusted (SELF_SIGNED_CERT_IN_CHAIN); clients will reject it\", \"Self-signed certificate\", \"Insecure TLS version in use: TLSv1.1\", and one HSTS finding: \"HSTS present\" or \"HSTS not configured\" when the port answered the HTTP request, or \"HSTS not checked — no HTTP response on port 993\" when it did not (a non-HTTP service such as IMAPS, SMTPS, or DNS over TLS). Empty when the connection never completed a handshake (rejected target, connection failure, or timeout) — the reason is in \"error\" only. A handshake that completed without a certificate keeps its TLS-session findings here alongside \"error\"."Output schema / properties / results / items / properties / port / descriptionPrevious value: -"The port used for the TLS connection."New value: +"The port used for the TLS connection: the port written on the entry, otherwise the \"port\" input."Output schema / properties / results / items / properties / status / descriptionPrevious value: -"Overall status. \"critical\" — the certificate expires in < 7 days or has already expired, the hostname is not covered by the certificate, chain verification failed (self-signed or untrusted root), or an insecure TLS version was negotiated; every one of these is rejected by ordinary clients. \"warning\" — expires in < 30 days. \"ok\" — none of the above. \"error\" — no certificate was retrieved: the domain was rejected, the connection failed or timed out, or the server presented no certificate; the reason is in \"error\"."New value: +"Overall status. \"critical\" — the certificate expires in < 7 days or has already expired, the hostname is not covered by the certificate, chain verification failed (self-signed or untrusted root), or an insecure TLS version was negotiated (TLS 1.0/1.1, including a server that offers nothing newer); every one of these is rejected by ordinary clients. \"warning\" — expires in < 30 days. \"ok\" — none of the above. Graded from the certificate and session alone: HSTS never changes it, and neither does what the port sends after the handshake. \"error\" — no certificate was retrieved: the entry was rejected, the connection failed or timed out before the handshake completed, or the server presented no certificate; the reason is in \"error\"."devops_check_dns19 fields changedInput schema / properties / domains / descriptionPrevious value: -"Domain names to query. Up to 10 per call."New value: +"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."Input schema / properties / domains / items / descriptionPrevious value: -"A domain name to query (e.g., \"github.com\", \"api.example.com\")."New value: +"A domain name to query (e.g., \"github.com\", \"_dmarc.example.com\"). A URL or a host:port is reduced to its host."Input schema / properties / domains / maxItemsPrevious value: -10New value: +100Input schema / properties / record_types / descriptionPrevious value: -"DNS record types to resolve. Defaults to A, AAAA, MX, and TXT. An empty array uses the same defaults. Add NS to check nameserver delegation. Add CNAME when investigating redirect chains."New value: +"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."Input schema / properties / record_types / items / enumPrevious value: -[
- "A",
- "AAAA",
- "CNAME",
- "MX",
- "TXT",
- "NS"
-]New value: +[
+ "A",
+ "AAAA",
+ "CNAME",
+ "MX",
+ "TXT",
+ "NS",
+ "CAA",
+ "SOA"
+]Input schema / properties / resolvers / descriptionPrevious value: -"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. 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."New value: +"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."Input schema / properties / resolvers / maxItemsAdded value: +20Input schema / properties / timeout_ms / descriptionPrevious value: -"Query timeout per domain+resolver combination in milliseconds. Defaults to the DEVOPS_STATUS_DNS_TIMEOUT_MS env var (3000 when unset)."New value: +"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."Input schema / properties / timeout_ms / maximumPrevious value: -10000New value: +9007199254740991Output schema / anyOfPrevious value: -[
- {
- "not": {
- "required": [
- "error"
- ]
- },
- "required": [
- "results"
- ]
- },
- {
- "required": [
- "error"
- ]
- }
-]New value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "results",
+ "deferred_domains",
+ "deferred_resolvers"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / deferred_domainsAdded value: +{
+ "description": "Domain entries past the first 10, not queried on this call, verbatim and in input order. Resend them in another call. Empty when every entry was queried.",
+ "items": {
+ "description": "A submitted domain entry, exactly as sent.",
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / deferred_resolversAdded value: +{
+ "description": "Distinct resolvers past the first 5, not queried on this call, verbatim and in input order. Resend them with the same domains in another call. Empty when every resolver was queried.",
+ "items": {
+ "description": "A submitted resolver entry, exactly as sent.",
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `invalid_domain`: A domain string contains a protocol prefix or invalid format. `target_blocked`: A resolver is a private, loopback, or otherwise non-public address, or is not an IP literal at all. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `target_blocked`: A resolver is a private, loopback, or otherwise non-public address, or is not an IP literal at all. Other values are possible when a failure originates below the handler."Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[
- "invalid_domain",
- "target_blocked"
-]New value: +[
+ "target_blocked"
+]Output schema / properties / noticeAdded value: +{
+ "description": "Present when the call was served at a bound: domains or resolvers past the per-call cap, named in deferred_domains and deferred_resolvers, or a timeout_ms over 10000 that was served as 10000. Absent otherwise.",
+ "type": "string"
+}Output schema / properties / results / items / properties / domain / descriptionPrevious value: -"The domain that was queried."New value: +"The domain name that was queried, as read from the submitted entry (lowercase, ASCII, no scheme, port, or path). For an entry that is not a domain name, the submitted string as given."Output schema / properties / results / items / properties / error / descriptionPrevious value: -"Set only when the domain could not be queried at all. Either it was rejected before any query (for example a private, loopback, or cloud-metadata target) and \"resolver_results\" is empty, or every resolver failed and none returned records, in which case each failing resolver is named with its own outcome (\"8.8.8.8: SERVFAIL on A; 1.1.1.1: NXDOMAIN on A\") so a split result stays visible. Null when at least one resolver answered; per-resolver failures are still in \"resolver_results\" and \"flags\"."New value: +"Set only when the domain could not be queried at all. Either it was rejected before any query — the entry is not a domain name (the message names the entry and the accepted shapes), or it is a private, loopback, or cloud-metadata target — and \"resolver_results\" is empty, or every resolver failed and none returned records, in which case each failing resolver is named with its own outcome (\"8.8.8.8: SERVFAIL on A; 1.1.1.1: NXDOMAIN on A\") so a split result stays visible. Null when at least one resolver answered; per-resolver failures are still in \"resolver_results\" and \"flags\"."Output schema / properties / results / items / properties / records / descriptionPrevious value: -"Resolved records from a single resolver, keyed by record type (A, AAAA, CNAME, MX, TXT, NS). Taken from the primary resolver (first in \"resolvers\"), or from the first resolver that returned records when the primary returned none. Read \"records_source\" for which resolver these came from, and \"resolver_results\" for the full per-resolver picture. This is also the reference set the per-resolver answers are reported against: a resolver that returned exactly these values for a type names it in \"records_same_as_domain\" rather than repeating them."New value: +"Resolved records from a single resolver, keyed by record type (A, AAAA, CNAME, MX, TXT, NS, CAA, SOA). Names carry no trailing dot; MX renders as \"<preference> <exchange>\", CAA as '<flags> <tag> \"<value>\"', and SOA as \"<primary nameserver> <hostmaster> <serial> <refresh> <retry> <expire> <minimum>\". Taken from the primary resolver (first in \"resolvers\"), or from the first resolver that returned records when the primary returned none. Read \"records_source\" for which resolver these came from, and \"resolver_results\" for the full per-resolver picture. This is also the reference set the per-resolver answers are reported against: a resolver that returned exactly these values for a type names it in \"records_same_as_domain\" rather than repeating them."Output schema / properties / results / items / properties / resolver_results / items / properties / status_by_type / descriptionPrevious value: -"Outcome for each requested record type, keyed by type. \"ok\" = records returned; \"nodata\" = the domain exists but has no record of this type; \"nxdomain\" = the domain does not exist (check for a typo, an expired registration, or a missing delegation); \"servfail\" = the resolver could not complete the query, commonly a DNSSEC validation failure; \"refused\" = the resolver declined; \"timeout\" = no answer within timeout_ms; \"error\" = any other failure, described in \"error\"."New value: +"Outcome for each requested record type, keyed by type. \"ok\" = records returned; \"nodata\" = the domain exists but has no record of this type; \"nxdomain\" = the domain does not exist (check for a typo, an expired registration, or a missing delegation); \"servfail\" = the resolver could not complete the query, commonly a DNSSEC validation failure; \"refused\" = the resolver declined the query or refused the connection; \"timeout\" = no answer within timeout_ms; \"error\" = any other failure, described in \"error\"."devops_get_incidents18 fields changedInput schema / properties / filter / descriptionPrevious value: -"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\", \"gcp\", and \"slack\" publish no maintenance windows. An empty result names which case applied."New value: +"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."Input schema / properties / full_updatesAdded value: +{
+ "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.",
+ "type": "boolean"
+}Input schema / properties / limit / descriptionPrevious value: -"Maximum incidents to return per call (1–50). Page through longer history with offset rather than raising this."New value: +"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."Input schema / properties / limit / maximumPrevious value: -50New value: +9007199254740991Input schema / properties / matchAdded value: +{
+ "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.",
+ "maxLength": 200,
+ "type": "string"
+}Input schema / properties / since / descriptionPrevious value: -"Earliest start date to include, as YYYY-MM-DD (UTC), at most 24 months back. 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. Omit to read only the status API."New value: +"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."Input schema / properties / untilAdded value: +{
+ "anyOf": [
+ {
+ "const": "",
+ "type": "string"
+ },
+ {
+ "description": "Latest start date to include, as YYYY-MM-DD (UTC), e.g. \"2025-10-31\".",
+ "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])))$",
+ "type": "string"
+ }
+ ],
+ "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."
+}Output schema / properties / cap / descriptionPrevious value: -"The limit that was applied. Present only when truncated."New value: +"The limit that was applied: the requested limit, or 50 when a larger one was requested. Present only when truncated."Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `vendor_not_found`: Vendor slug not in registry and input is not a valid URL. `target_blocked`: A raw URL resolves to a private, loopback, or cloud-metadata address. `invalid_since`: since was passed with filter \"active\" or \"scheduled\", or is more than 24 months back. `statuspage_unavailable`: The vendor's status API returned an error or timed out. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `vendor_not_found`: Vendor slug not in registry and input is not a valid URL. `target_blocked`: A raw URL resolves to a private, loopback, or cloud-metadata address. `invalid_since`: since was passed with filter \"active\" or \"scheduled\". `invalid_until`: until was passed with filter \"active\" or \"scheduled\", or names a date earlier than the since date. `statuspage_unavailable`: The vendor's status API returned an error or timed out. Other values are possible when a failure originates below the handler."Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[
- "vendor_not_found",
- "target_blocked",
- "invalid_since",
- "statuspage_unavailable"
-]New value: +[
+ "vendor_not_found",
+ "target_blocked",
+ "invalid_since",
+ "invalid_until",
+ "statuspage_unavailable"
+]Output schema / properties / incidents / items / properties / updates / descriptionPrevious value: -"Chronological list of incident updates (oldest first). A history-archive record carries only its final update, dated at its end time (or its start when it has none)."New value: +"Chronological list of incident updates (oldest first). A history-archive record carries only its final update, dated at its end time (or its start when it has none). An incident too large for the response size budget on its own carries only its newest updates, and updates_omitted counts the rest."Output schema / properties / incidents / items / properties / updates / items / properties / body / descriptionPrevious value: -"Update text from the vendor."New value: +"Update text from the vendor, as plain text: HTML markup the vendor published is converted (a link reads as its text, then its URL), and any other < is text the vendor wrote."Output schema / properties / incidents / items / properties / updates_omittedAdded value: +{
+ "description": "How many of this incident's oldest updates were left out because it alone exceeds the response size budget; the updates returned are its newest. Absent when every update is returned. Call again with full_updates: true and limit: 1 at this incident's offset to read them all.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+}Output schema / properties / notice / descriptionPrevious value: -"Plain-language explanation of this result — how to page onward, why it came back empty (the vendor currently publishes nothing at all, a filter the backend cannot satisfy, an offset past the end, or a since date that left everything out), that the vendor feed capped the history, or how far the history archive was read when it stopped short of since. Absent when the result needs no explanation."New value: +"Plain-language explanation of this result — a limit over 50 that was served as 50 (with the requested and effective values), a since older than the 24-month history-archive floor (with the date the archive was read back to), how to page onward, that the page stopped at the response size budget or left out an oversized incident's oldest updates (and the call that returns them all), why it came back empty (the vendor currently publishes nothing at all, a filter the backend cannot satisfy, an offset past the end, a since/until range or match words that left everything out — naming the archive floor when the range starts before it), that the vendor feed capped the history, or how far the history archive was read when it stopped short of since or its floor. Absent when the result needs no explanation."Output schema / properties / shown / descriptionPrevious value: -"Number of incidents returned after applying the limit. Present only when truncated."New value: +"Number of incidents on this page: the limit, or fewer when the page stopped at the response size budget. Present only when truncated."Output schema / properties / totalCount / descriptionPrevious value: -"Total incidents matching the filter, across all pages, before offset/limit windowing. Present only when the result was truncated."New value: +"Total incidents matching the filter, date range, and match, across all pages, before offset/limit windowing. Present only when the result was truncated."Output schema / properties / truncated / descriptionPrevious value: -"True when more incidents matched than the limit returned. Absent when the result was not capped."New value: +"True when more incidents matched than this page returned — because of limit, or because the page stopped at the response size budget. Absent when this page reached the end of the matches."Output schema / properties / upstreamCeiling / descriptionPrevious value: -"Maximum incidents the vendor's own status API serves in one fetch, present only when that ceiling was reached on this call. It bounds the history independently of limit and offset: incidents older than the oldest one returned cannot be fetched at any offset. On Atlassian Statuspage vendors, since reads past it from the page's history archive. Absent when the vendor feed is unbounded, returned less than its ceiling, or since was set and the history archive was read back to it."New value: +"Maximum incidents the vendor's own status API serves in one fetch, present only when that ceiling was reached on this call. It bounds the history independently of limit and offset: incidents older than the oldest one returned cannot be fetched at any offset. On Atlassian Statuspage vendors, since reads past it from the page's history archive, except on a vendor that covers only part of a shared page, such as \"sendgrid\". Absent when the vendor feed is unbounded, returned less than its ceiling, or since was set and the history archive was read back to it (or to its 24-month floor, when since is older)."devops_list_vendors3 fields changedInput schema / properties / query / descriptionPrevious value: -"Free-text search against vendor name and slug. Case-insensitive. E.g., \"cloud\", \"auth\", \"slack\"."New value: +"Substring search against vendor slug and display name. Case-insensitive; surrounding whitespace is ignored. E.g., \"cloud\", \"auth\", \"slack\"."Output schema / properties / noticeAdded value: +{
+ "description": "Why nothing matched and what to call next. Present only when vendors is empty.",
+ "type": "string"
+}Output schema / properties / vendors / items / properties / statuspage_url / descriptionPrevious value: -"Status page base URL — the Statuspage API base for Statuspage-backed vendors, the public status page URL for adapter-backed vendors (aws, gcp, azure, gitlab, slack, neon, redis-cloud)."New value: +"Status page base URL — the Statuspage API base for Statuspage-backed vendors, the public status page URL for adapter-backed vendors (aws, gcp, azure, azure-devops, gitlab, slack, neon, redis-cloud)."devops_status_check20 fields changedInput schema / properties / component_filter / descriptionPrevious value: -"Case-insensitive substring matched against component names in detailed mode (e.g., \"api\" to check just the API components). Applied before component_limit, so it is the way to reach a component that the cap would otherwise omit. Ignored in summary mode."New value: +"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."Input schema / properties / component_limit / descriptionPrevious value: -"Maximum components returned per vendor in detailed mode (1-500). 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."New value: +"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."Input schema / properties / component_limit / maximumPrevious value: -500New value: +9007199254740991Input schema / properties / vendors / descriptionPrevious value: -"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."New value: +"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."Input schema / properties / vendors / maxItemsPrevious value: -20New value: +100Output schema / anyOfPrevious value: -[
- {
- "not": {
- "required": [
- "error"
- ]
- },
- "required": [
- "results",
- "summary",
- "nextToolSuggestions"
- ]
- },
- {
- "required": [
- "error"
- ]
- }
-]New value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "results",
+ "deferred_vendors",
+ "summary",
+ "nextToolSuggestions"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / deferred_vendorsAdded value: +{
+ "description": "Entries past the first 20 in vendors, verbatim and in input order. They were not checked; resend them in another call. Empty when every entry was checked.",
+ "items": {
+ "description": "A vendor entry exactly as provided.",
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `vendor_not_found`: No requested vendor could be checked and the first failure was a slug that matches no registry entry and is not a valid URL. `target_blocked`: No requested vendor could be checked and the first failure was a raw URL resolving to a private, loopback, or cloud-metadata address. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `vendor_not_found`: No requested vendor among the first 20 could be checked and the first failure was a slug that matches no registry entry and is not a valid URL. `target_blocked`: No requested vendor among the first 20 could be checked and the first failure was a raw URL resolving to a private, loopback, or cloud-metadata address. Other values are possible when a failure originates below the handler."Output schema / properties / nextToolSuggestions / items / properties / args / descriptionPrevious value: -"Ready-to-use devops_suggest_action arguments: vendor (registry slug, or the normalized status page URL for a raw URL), vendor_indicator (only for minor, major, or critical), affected_components (degraded components outside a maintenance window), incident_summary (title of the most recently started open incident rated minor or worse)."New value: +"Ready-to-use devops_suggest_action arguments: vendor (registry slug, or the normalized status page URL for a raw URL), vendor_indicator (only for minor, major, or critical), affected_components (degraded components outside a maintenance window, each written \"Group / Leaf\" when it is in a group), incident_summary (title of the most recently started open incident rated minor or worse)."Output schema / properties / notice / descriptionPrevious value: -"Plain-language explanation of the capped component lists — how many components were omitted and how to reach them (component_filter to target one, component_limit to raise the cap). Present only when truncated."New value: +"Plain-language explanation of what this call left out or adjusted: vendors past the first 20 (listed in deferred_vendors), a component_limit above 500 reduced to 500, and in detailed mode how many components the cap omitted and how to reach them (component_filter to target one, or component_limit to raise a cap below 500), and which checked vendors component_filter matched no component of, with how many each publishes. Present only when one of these applies."Output schema / properties / results / descriptionPrevious value: -"Per-vendor status results in the same order as the input vendors list."New value: +"Per-vendor status results for the vendors checked, in the same order as the input vendors list."Output schema / properties / results / items / properties / active_incidents / items / properties / latest_update / descriptionPrevious value: -"Most recent incident_update body text."New value: +"Most recent update text, as plain text: HTML markup the vendor published is converted, and any other < is text the vendor wrote."Output schema / properties / results / items / properties / all_components / descriptionPrevious value: -"Components including operational ones, capped at component_limit per vendor and narrowed by component_filter when given. Present in detailed mode only."New value: +"Components including operational ones, capped at component_limit per vendor and narrowed by component_filter (matched against name and group) when given. Present in detailed mode only."Output schema / properties / results / items / properties / all_components / items / properties / groupAdded value: +{
+ "description": "Name of the group the status page files this component under — typically the product or region it belongs to — or null when it is not in a group.",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / results / items / properties / all_components / items / properties / name / descriptionPrevious value: -"Component name."New value: +"Component name as the status page publishes it — the leaf alone, without its group. Several leaves can share a name (one per region or product); group tells them apart."Output schema / properties / results / items / properties / all_components / items / requiredPrevious value: -[
- "name",
- "status",
- "description"
-]New value: +[
+ "name",
+ "group",
+ "status",
+ "description"
+]Output schema / properties / results / items / properties / degraded_components / items / properties / groupAdded value: +{
+ "description": "Name of the group the status page files this component under — typically the product or region it belongs to — or null when it is not in a group.",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / results / items / properties / degraded_components / items / properties / name / descriptionPrevious value: -"Component name."New value: +"Component name as the status page publishes it — the leaf alone, without its group. Several leaves can share a name (one per region or product); group tells them apart."Output schema / properties / results / items / properties / degraded_components / items / requiredPrevious value: -[
- "name",
- "status"
-]New value: +[
+ "name",
+ "group",
+ "status"
+]Output schema / properties / summary / properties / total / descriptionPrevious value: -"Total number of vendors checked."New value: +"Total number of vendors checked — never counts deferred_vendors."devops_suggest_action3 fields changedInput schema / properties / affected_components / descriptionPrevious value: -"Component names affected (from devops_status_check degraded_components or devops_get_incidents affected_components). Used to tailor suggestions to the impacted subsystem."New value: +"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."Input schema / properties / vendor / descriptionPrevious value: -"Vendor slug or display name (e.g., \"cloudflare\", \"github\"). Used to tailor category-specific guidance (CDN outage vs. CI/CD outage vs. auth provider outage)."New value: +"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."Output schema / properties / nextToolSuggestions / items / properties / toolName / descriptionPrevious value: -"Tool to call next (e.g., \"devops_check_dns\", \"devops_check_certs\")."New value: +"Tool to call next (e.g., \"devops_get_incidents\", \"devops_list_vendors\", \"devops_check_dns\")."devops_watch_stack23 fields changedInput schema / properties / component_filter / descriptionPrevious value: -"Case-insensitive substring matched against component names in detailed mode (e.g., \"api\" to check just the API components). Applied before component_limit, so it is the way to reach a component that the cap would otherwise omit. Ignored in summary mode."New value: +"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."Input schema / properties / component_limit / descriptionPrevious value: -"Maximum components returned per vendor in detailed mode (1-500). 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."New value: +"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."Input schema / properties / component_limit / maximumPrevious value: -500New value: +9007199254740991Input schema / properties / vendors / descriptionPrevious value: -"Vendor slugs (e.g., \"github\", \"aws\") or raw Atlassian Statuspage base URLs. When provided, saves this list as the stack. When omitted, uses the previously saved list for stack_name."New value: +"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."Input schema / properties / vendors / maxItemsAdded value: +100Output schema / anyOfPrevious value: -[
- {
- "not": {
- "required": [
- "error"
- ]
- },
- "required": [
- "stack_name",
- "health",
- "summary",
- "vendors",
- "stack_persisted",
- "omitted_vendors",
- "checked_at",
- "nextToolSuggestions"
- ]
- },
- {
- "required": [
- "error"
- ]
- }
-]New value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "stack_name",
+ "health",
+ "summary",
+ "vendors",
+ "deferred_vendors",
+ "stack_persisted",
+ "omitted_vendors",
+ "checked_at",
+ "nextToolSuggestions"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / deferred_vendorsAdded value: +{
+ "description": "Entries past the first 20, verbatim and in order, that were not checked on this call: the rest of a passed vendors list on a deployment that saves no stacks, or of a saved stack holding more than 20. Resend them in another call. Empty when every entry was checked.",
+ "items": {
+ "description": "A vendor entry exactly as provided or saved.",
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `no_stack`: No vendors provided and no saved stack found for stack_name. `vendor_not_found`: No vendor in the stack could be checked and the first failure was a slug that is not in the registry and is not a valid URL. `target_blocked`: No vendor in the stack could be checked and the first failure was a raw URL resolving to a private, loopback, or cloud-metadata address. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `no_stack`: No vendors provided and no saved stack found for stack_name. `vendors_required`: No vendors provided on a deployment that saves no stacks because callers are not authenticated. `stack_too_large`: More than 20 vendors were provided on a deployment that saves stacks, so nothing was saved. `vendor_not_found`: No vendor in the stack could be checked and the first failure was a slug that is not in the registry and is not a valid URL. `target_blocked`: No vendor in the stack could be checked and the first failure was a raw URL resolving to a private, loopback, or cloud-metadata address. Other values are possible when a failure originates below the handler."Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[
- "no_stack",
- "vendor_not_found",
- "target_blocked"
-]New value: +[
+ "no_stack",
+ "vendors_required",
+ "stack_too_large",
+ "vendor_not_found",
+ "target_blocked"
+]Output schema / properties / nextToolSuggestions / items / properties / args / descriptionPrevious value: -"Ready-to-use devops_suggest_action arguments: vendor (registry slug, or the normalized status page URL for a raw URL), vendor_indicator (only for minor, major, or critical), affected_components (degraded components outside a maintenance window), incident_summary (title of the most recently started open incident rated minor or worse)."New value: +"Ready-to-use devops_suggest_action arguments: vendor (registry slug, or the normalized status page URL for a raw URL), vendor_indicator (only for minor, major, or critical), affected_components (degraded components outside a maintenance window, each written \"Group / Leaf\" when it is in a group), incident_summary (title of the most recently started open incident rated minor or worse)."Output schema / properties / notice / descriptionPrevious value: -"Plain-language explanation of the capped component lists — how many components were omitted and how to reach them (component_filter to target one, component_limit to raise the cap). Present only when truncated."New value: +"Plain-language explanation of what this call left out or adjusted: vendors past the first 20 (listed in deferred_vendors), a component_limit above 500 reduced to 500, and in detailed mode how many components the cap omitted and how to reach them (component_filter to target one, or component_limit to raise a cap below 500), and which checked vendors component_filter matched no component of, with how many each publishes. Present only when one of these applies."Output schema / properties / persistence_noticeAdded value: +{
+ "description": "Present when this deployment saves no stacks because callers are not authenticated: nothing was saved, and vendors must be passed on every call.",
+ "type": "string"
+}Output schema / properties / stack_persisted / descriptionPrevious value: -"True when the vendor list was saved to state on this call. Only the vendors that resolved are saved — see omitted_vendors."New value: +"True when the vendor list was saved on this call. Only the vendors that resolved are saved — see omitted_vendors. Always false on a deployment that does not authenticate callers, which saves no stacks (persistence_notice says so)."Output schema / properties / summary / properties / total / descriptionPrevious value: -"Total vendors in the stack."New value: +"Total vendors checked on this call — never counts deferred_vendors."Output schema / properties / vendors / descriptionPrevious value: -"Per-vendor status results."New value: +"Per-vendor status results for the vendors checked, in stack order."Output schema / properties / vendors / items / properties / active_incidents / items / properties / latest_update / descriptionPrevious value: -"Most recent incident_update body text."New value: +"Most recent update text, as plain text: HTML markup the vendor published is converted, and any other < is text the vendor wrote."Output schema / properties / vendors / items / properties / all_components / descriptionPrevious value: -"Components including operational ones, capped at component_limit per vendor and narrowed by component_filter when given. Present in detailed mode only."New value: +"Components including operational ones, capped at component_limit per vendor and narrowed by component_filter (matched against name and group) when given. Present in detailed mode only."Output schema / properties / vendors / items / properties / all_components / items / properties / groupAdded value: +{
+ "description": "Name of the group the status page files this component under — typically the product or region it belongs to — or null when it is not in a group.",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / vendors / items / properties / all_components / items / properties / name / descriptionPrevious value: -"Component name."New value: +"Component name as the status page publishes it — the leaf alone, without its group. Several leaves can share a name (one per region or product); group tells them apart."Output schema / properties / vendors / items / properties / all_components / items / requiredPrevious value: -[
- "name",
- "status",
- "description"
-]New value: +[
+ "name",
+ "group",
+ "status",
+ "description"
+]Output schema / properties / vendors / items / properties / degraded_components / items / properties / groupAdded value: +{
+ "description": "Name of the group the status page files this component under — typically the product or region it belongs to — or null when it is not in a group.",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / vendors / items / properties / degraded_components / items / properties / name / descriptionPrevious value: -"Component name."New value: +"Component name as the status page publishes it — the leaf alone, without its group. Several leaves can share a name (one per region or product); group tells them apart."Output schema / properties / vendors / items / properties / degraded_components / items / requiredPrevious value: -[
- "name",
- "status"
-]New value: +[
+ "name",
+ "group",
+ "status"
+]devops_get_incidents16 fields changedInput schema / properties / filter / descriptionPrevious value: -"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\" publishes currently-open events only (never resolved, no maintenance windows), and \"gcp\" and \"slack\" publish no maintenance windows. An empty result names which case applied."New value: +"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\", \"gcp\", and \"slack\" publish no maintenance windows. An empty result names which case applied."Input schema / properties / sinceAdded value: +{
+ "anyOf": [
+ {
+ "const": "",
+ "type": "string"
+ },
+ {
+ "description": "Earliest start date to include, as YYYY-MM-DD (UTC), e.g. \"2025-10-01\".",
+ "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])))$",
+ "type": "string"
+ }
+ ],
+ "description": "Earliest start date to include, as YYYY-MM-DD (UTC), at most 24 months back. 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. Omit to read only the status API."
+}Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `vendor_not_found`: Vendor slug not in registry and input is not a valid URL. `target_blocked`: A raw URL resolves to a private, loopback, or cloud-metadata address. `statuspage_unavailable`: The vendor's status API returned an error or timed out. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `vendor_not_found`: Vendor slug not in registry and input is not a valid URL. `target_blocked`: A raw URL resolves to a private, loopback, or cloud-metadata address. `invalid_since`: since was passed with filter \"active\" or \"scheduled\", or is more than 24 months back. `statuspage_unavailable`: The vendor's status API returned an error or timed out. Other values are possible when a failure originates below the handler."Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[
- "vendor_not_found",
- "target_blocked",
- "statuspage_unavailable"
-]New value: +[
+ "vendor_not_found",
+ "target_blocked",
+ "invalid_since",
+ "statuspage_unavailable"
+]Output schema / properties / incidents / items / properties / created_at / descriptionPrevious value: -"ISO 8601 UTC timestamp when the incident was created."New value: +"ISO 8601 timestamp when the incident was created, carrying the UTC offset the vendor published (Z, +00:00, or a local offset such as -07:00). For a history-archive record, the start time its status page displays, to the minute, in UTC."Output schema / properties / incidents / items / properties / resolved_at / descriptionPrevious value: -"ISO 8601 UTC timestamp when resolved, or null if still active."New value: +"ISO 8601 timestamp, with the vendor's UTC offset, when resolved, or null if still active. For a history-archive record, to the minute, in UTC."Output schema / properties / incidents / items / properties / scheduled_for / descriptionPrevious value: -"Present for scheduled maintenances — ISO 8601 UTC start time."New value: +"Present for scheduled maintenances — ISO 8601 start time with the vendor's UTC offset."Output schema / properties / incidents / items / properties / scheduled_until / descriptionPrevious value: -"Present for scheduled maintenances — ISO 8601 UTC end time."New value: +"Present for scheduled maintenances — ISO 8601 end time with the vendor's UTC offset."Output schema / properties / incidents / items / properties / sourceAdded value: +{
+ "description": "Where this record came from. api: the vendor's status API, with the full update timeline and affected components. history: the status page's quarterly history archive, read only when since is set — title, impact, start and end times, and the final update message, with no components and no started_at, scheduled window, or duration.",
+ "enum": [
+ "api",
+ "history"
+ ],
+ "type": "string"
+}Output schema / properties / incidents / items / properties / started_at / descriptionPrevious value: -"ISO 8601 UTC timestamp when the incident started, or null/absent if not set by the vendor."New value: +"ISO 8601 timestamp, with the vendor's UTC offset, when the incident started, or null/absent if not set by the vendor."Output schema / properties / incidents / items / properties / status / descriptionPrevious value: -"Current status: investigating | identified | monitoring | resolved | postmortem | scheduled | in_progress | completed."New value: +"Current status: investigating | identified | monitoring | resolved | postmortem | scheduled | in_progress | completed | unknown. unknown marks a history-archive record with no end time, whose lifecycle stage the archive does not publish."Output schema / properties / incidents / items / properties / updates / descriptionPrevious value: -"Chronological list of incident updates (oldest first)."New value: +"Chronological list of incident updates (oldest first). A history-archive record carries only its final update, dated at its end time (or its start when it has none)."Output schema / properties / incidents / items / properties / updates / items / properties / created_at / descriptionPrevious value: -"ISO 8601 UTC timestamp of this update."New value: +"ISO 8601 timestamp of this update, with the vendor's UTC offset."Output schema / properties / incidents / items / requiredPrevious value: -[
- "id",
- "name",
- "impact",
- "status",
- "created_at",
- "resolved_at",
- "scheduled_for",
- "scheduled_until",
- "duration_minutes",
- "affected_components",
- "updates"
-]New value: +[
+ "id",
+ "name",
+ "impact",
+ "status",
+ "created_at",
+ "resolved_at",
+ "scheduled_for",
+ "scheduled_until",
+ "duration_minutes",
+ "affected_components",
+ "updates",
+ "source"
+]Output schema / properties / notice / descriptionPrevious value: -"Plain-language explanation of this result — how to page onward, why it came back empty (the vendor currently publishes nothing at all, a filter the backend cannot satisfy, or an offset past the end), or that the vendor feed capped the history. Absent when the result needs no explanation."New value: +"Plain-language explanation of this result — how to page onward, why it came back empty (the vendor currently publishes nothing at all, a filter the backend cannot satisfy, an offset past the end, or a since date that left everything out), that the vendor feed capped the history, or how far the history archive was read when it stopped short of since. Absent when the result needs no explanation."Output schema / properties / upstreamCeiling / descriptionPrevious value: -"Maximum incidents the vendor's own status API serves in one fetch, present only when that ceiling was reached on this call. It bounds the history independently of limit and offset: incidents older than the oldest one returned cannot be fetched at any offset, only browsed on the vendor status page. Absent when the vendor feed is unbounded or returned less than its ceiling."New value: +"Maximum incidents the vendor's own status API serves in one fetch, present only when that ceiling was reached on this call. It bounds the history independently of limit and offset: incidents older than the oldest one returned cannot be fetched at any offset. On Atlassian Statuspage vendors, since reads past it from the page's history archive. Absent when the vendor feed is unbounded, returned less than its ceiling, or since was set and the history archive was read back to it."devops_list_vendors1 field changedOutput schema / properties / vendors / items / properties / statuspage_url / descriptionPrevious value: -"Status page base URL — the Statuspage API base for Statuspage-backed vendors, the public status page URL for adapter-backed vendors (aws, gcp, gitlab, slack, neon, redis-cloud)."New value: +"Status page base URL — the Statuspage API base for Statuspage-backed vendors, the public status page URL for adapter-backed vendors (aws, gcp, azure, gitlab, slack, neon, redis-cloud)."devops_status_check3 fields changedOutput schema / properties / results / items / properties / active_incidents / items / properties / started_at / descriptionPrevious value: -"ISO 8601 UTC timestamp when the incident started, or null/absent if not set by the vendor."New value: +"ISO 8601 timestamp, with the vendor's UTC offset (Z, +00:00, or a local offset such as -07:00), when the incident started, or null/absent if not set by the vendor."Output schema / properties / results / items / properties / scheduled_maintenances / items / properties / scheduled_for / descriptionPrevious value: -"ISO 8601 UTC start time."New value: +"ISO 8601 start time, with the vendor's UTC offset."Output schema / properties / results / items / properties / scheduled_maintenances / items / properties / scheduled_until / descriptionPrevious value: -"ISO 8601 UTC end time."New value: +"ISO 8601 end time, with the vendor's UTC offset."devops_watch_stack3 fields changedOutput schema / properties / vendors / items / properties / active_incidents / items / properties / started_at / descriptionPrevious value: -"ISO 8601 UTC timestamp when the incident started, or null/absent if not set by the vendor."New value: +"ISO 8601 timestamp, with the vendor's UTC offset (Z, +00:00, or a local offset such as -07:00), when the incident started, or null/absent if not set by the vendor."Output schema / properties / vendors / items / properties / scheduled_maintenances / items / properties / scheduled_for / descriptionPrevious value: -"ISO 8601 UTC start time."New value: +"ISO 8601 start time, with the vendor's UTC offset."Output schema / properties / vendors / items / properties / scheduled_maintenances / items / properties / scheduled_until / descriptionPrevious value: -"ISO 8601 UTC end time."New value: +"ISO 8601 end time, with the vendor's UTC offset."devops_check_certs5 fields changedOutput schema / properties / results / items / properties / cert / descriptionPrevious value: -"Certificate details, or null when connection failed (error status)."New value: +"Certificate details, or null when no certificate was retrieved (status \"error\")."Output schema / properties / results / items / properties / error / descriptionPrevious value: -"Connection error message when status is \"error\"."New value: +"Why status is \"error\". Either no handshake completed — the domain was rejected as a private, loopback, or cloud-metadata target, a connection failure such as \"getaddrinfo ENOTFOUND …\", or \"Timed out after 5000ms\" — with cert and tls null and flags empty; or the handshake completed but the server presented no certificate, with cert null and the TLS session still reported in tls and flags. Null for every other status."Output schema / properties / results / items / properties / flags / descriptionPrevious value: -"Human-readable warnings and issues found: \"Expires in 12 days (warning)\", \"Certificate expired 40 days ago\", \"Hostname mismatch — the certificate does not cover api.example.com; clients will reject it\", \"Certificate chain not trusted (SELF_SIGNED_CERT_IN_CHAIN); clients will reject it\", \"Self-signed certificate\", \"Insecure TLS version in use: TLSv1.1\", \"HSTS present\" / \"HSTS not configured\"."New value: +"Human-readable findings about the certificate and TLS session that were read: \"Expires in 12 days (warning)\", \"Certificate expired 40 days ago\", \"Hostname mismatch — the certificate does not cover api.example.com; clients will reject it\", \"Certificate chain not trusted (SELF_SIGNED_CERT_IN_CHAIN); clients will reject it\", \"Self-signed certificate\", \"Insecure TLS version in use: TLSv1.1\", \"HSTS present\" / \"HSTS not configured\". Empty when the connection never completed a handshake (rejected target, connection failure, or timeout) — the reason is in \"error\" only. A handshake that completed without a certificate keeps its TLS-session findings here alongside \"error\"."Output schema / properties / results / items / properties / status / descriptionPrevious value: -"Overall status. \"critical\" — the certificate expires in < 7 days or has already expired, the hostname is not covered by the certificate, chain verification failed (self-signed or untrusted root), or an insecure TLS version was negotiated; every one of these is rejected by ordinary clients. \"warning\" — expires in < 30 days. \"ok\" — none of the above. \"error\" — the connection failed and no certificate was retrieved."New value: +"Overall status. \"critical\" — the certificate expires in < 7 days or has already expired, the hostname is not covered by the certificate, chain verification failed (self-signed or untrusted root), or an insecure TLS version was negotiated; every one of these is rejected by ordinary clients. \"warning\" — expires in < 30 days. \"ok\" — none of the above. \"error\" — no certificate was retrieved: the domain was rejected, the connection failed or timed out, or the server presented no certificate; the reason is in \"error\"."Output schema / properties / results / items / properties / tls / descriptionPrevious value: -"TLS session details, or null when connection failed."New value: +"TLS session details, or null when no TLS handshake completed."devops_check_dns4 fields changedInput schema / properties / record_types / descriptionPrevious value: -"DNS record types to resolve. Defaults to A, AAAA, MX, and TXT. Add NS to check nameserver delegation. Add CNAME when investigating redirect chains."New value: +"DNS record types to resolve. Defaults to A, AAAA, MX, and TXT. An empty array uses the same defaults. Add NS to check nameserver delegation. Add CNAME when investigating redirect chains."Input schema / properties / resolvers / descriptionPrevious value: -"Resolver IP addresses to query. Defaults to Google (8.8.8.8), Cloudflare (1.1.1.1), and Quad9 (9.9.9.9). Add custom resolvers to test resolver-specific behavior. 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."New value: +"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. 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."Output schema / properties / results / items / properties / error / descriptionPrevious value: -"Set only when the domain could not be queried at all — every resolver failed and none returned records. Each failing resolver is named with its own outcome (\"8.8.8.8: SERVFAIL on A; 1.1.1.1: NXDOMAIN on A\") so a split result stays visible. Null when at least one resolver answered; per-resolver failures are still in \"resolver_results\" and \"flags\"."New value: +"Set only when the domain could not be queried at all. Either it was rejected before any query (for example a private, loopback, or cloud-metadata target) and \"resolver_results\" is empty, or every resolver failed and none returned records, in which case each failing resolver is named with its own outcome (\"8.8.8.8: SERVFAIL on A; 1.1.1.1: NXDOMAIN on A\") so a split result stays visible. Null when at least one resolver answered; per-resolver failures are still in \"resolver_results\" and \"flags\"."Output schema / properties / results / items / properties / flags / descriptionPrevious value: -"Human-readable observations that need attention: \"NXDOMAIN from 8.8.8.8, 1.1.1.1 on A, MX — the domain does not exist …\", \"Partial resolution on A records — 9.9.9.9 (nodata) returned nothing while 8.8.8.8 answered\", \"No MX records found\", \"CNAME detected — further records resolve via the CNAME target\". A value_variation disagreement is not flagged here — it is reported in \"propagation_discrepancies\" because it is normal for geo-steered domains."New value: +"Human-readable observations that need attention: \"NXDOMAIN from 8.8.8.8, 1.1.1.1 on A, MX — the domain does not exist …\", \"Partial resolution on A records — 9.9.9.9 (nodata) returned nothing while 8.8.8.8 answered\", \"No MX records found\", \"CNAME detected — further records resolve via the CNAME target\". A value_variation disagreement is not flagged here — it is reported in \"propagation_discrepancies\" because it is normal for geo-steered domains. Empty for a domain rejected before any query, whose reason is in \"error\"."devops_status_check2 fields changedOutput schema / anyOfPrevious value: -[
- {
- "not": {
- "required": [
- "error"
- ]
- },
- "required": [
- "results",
- "summary"
- ]
- },
- {
- "required": [
- "error"
- ]
- }
-]New value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "results",
+ "summary",
+ "nextToolSuggestions"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / nextToolSuggestionsAdded value: +{
+ "description": "One devops_suggest_action call per vendor with an active problem — an indicator of minor, major, or critical, or an open incident of that impact even while the indicator reads none or maintenance — with its arguments filled from that vendor's result. Vendors that could not be checked never appear. Empty when no checked vendor has an active problem.",
+ "items": {
+ "additionalProperties": false,
+ "description": "A recommended follow-up tool call with pre-filled arguments.",
+ "properties": {
+ "args": {
+ "additionalProperties": {},
+ "description": "Ready-to-use devops_suggest_action arguments: vendor (registry slug, or the normalized status page URL for a raw URL), vendor_indicator (only for minor, major, or critical), affected_components (degraded components outside a maintenance window), incident_summary (title of the most recently started open incident rated minor or worse).",
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "reason": {
+ "description": "Why the vendor qualifies: its reported indicator, or the open incident behind it.",
+ "type": "string"
+ },
+ "toolName": {
+ "description": "Tool to call next — \"devops_suggest_action\".",
+ "type": "string"
+ }
+ },
+ "required": [
+ "toolName",
+ "reason",
+ "args"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}devops_watch_stack2 fields changedOutput schema / anyOfPrevious value: -[
- {
- "not": {
- "required": [
- "error"
- ]
- },
- "required": [
- "stack_name",
- "health",
- "summary",
- "vendors",
- "stack_persisted",
- "omitted_vendors",
- "checked_at"
- ]
- },
- {
- "required": [
- "error"
- ]
- }
-]New value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "stack_name",
+ "health",
+ "summary",
+ "vendors",
+ "stack_persisted",
+ "omitted_vendors",
+ "checked_at",
+ "nextToolSuggestions"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / nextToolSuggestionsAdded value: +{
+ "description": "One devops_suggest_action call per vendor with an active problem — an indicator of minor, major, or critical, or an open incident of that impact even while the indicator reads none or maintenance — with its arguments filled from that vendor's result. Vendors that could not be checked never appear. Empty when no checked vendor has an active problem.",
+ "items": {
+ "additionalProperties": false,
+ "description": "A recommended follow-up tool call with pre-filled arguments.",
+ "properties": {
+ "args": {
+ "additionalProperties": {},
+ "description": "Ready-to-use devops_suggest_action arguments: vendor (registry slug, or the normalized status page URL for a raw URL), vendor_indicator (only for minor, major, or critical), affected_components (degraded components outside a maintenance window), incident_summary (title of the most recently started open incident rated minor or worse).",
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "reason": {
+ "description": "Why the vendor qualifies: its reported indicator, or the open incident behind it.",
+ "type": "string"
+ },
+ "toolName": {
+ "description": "Tool to call next — \"devops_suggest_action\".",
+ "type": "string"
+ }
+ },
+ "required": [
+ "toolName",
+ "reason",
+ "args"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}devops_check_certs3 fields changedOutput schema / properties / results / items / properties / cert / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "authorization_error": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "description": "OpenSSL chain-verification code when the certificate chain does not validate against the system trust store, or null when it validates. Common values: \"DEPTH_ZERO_SELF_SIGNED_CERT\" (self-signed leaf), \"SELF_SIGNED_CERT_IN_CHAIN\" / \"UNABLE_TO_VERIFY_LEAF_SIGNATURE\" (issuing root not trusted), \"CERT_HAS_EXPIRED\" (also reported in \"days_until_expiry\"). This is the authoritative chain-trust signal — the issuer and subject fields alone cannot detect an untrusted root."
- },
- "chain_depth": {
- "anyOf": [
- {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- {
- "type": "null"
- }
- ],
- "description": "Number of certificates the server sent, counting the leaf. Null when the runtime does not expose the issuer chain — read \"chain_depth_unavailable_reason\" in that case. Not a self-signed indicator: use \"authorization_error\" for that."
- },
- "chain_depth_unavailable_reason": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "description": "Why \"chain_depth\" is null, or null when a depth was measured. Absence of a depth is a runtime limitation, not a finding about the certificate."
- },
- "days_until_expiry": {
- "description": "Days remaining until certificate expiry. Negative = already expired.",
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- "hostname_verification_error": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "description": "Node's hostname-verification message when the requested domain is not covered by the certificate's CN or SANs (e.g. \"Hostname/IP does not match certificate's altnames: …\"), or null when the hostname is covered. A non-null value means ordinary clients reject this certificate for this hostname; compare against the \"san\" list to see what it does cover."
- },
- "issuer": {
- "description": "Issuer common name.",
- "type": "string"
- },
- "san": {
- "description": "Subject Alternative Names covered by this certificate.",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "serial": {
- "description": "Certificate serial number.",
- "type": "string"
- },
- "subject": {
- "description": "Certificate subject CN.",
- "type": "string"
- },
- "valid_from": {
- "description": "ISO 8601 UTC timestamp of certificate validity start.",
- "type": "string"
- },
- "valid_until": {
- "description": "ISO 8601 UTC timestamp of certificate expiry.",
- "type": "string"
- }
- },
- "required": [
- "subject",
- "san",
- "issuer",
- "valid_from",
- "valid_until",
- "days_until_expiry",
- "chain_depth",
- "chain_depth_unavailable_reason",
- "hostname_verification_error",
- "authorization_error",
- "serial"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "authorization_error": {
+ "description": "OpenSSL chain-verification code when the certificate chain does not validate against the system trust store, or null when it validates. Common values: \"DEPTH_ZERO_SELF_SIGNED_CERT\" (self-signed leaf), \"SELF_SIGNED_CERT_IN_CHAIN\" / \"UNABLE_TO_VERIFY_LEAF_SIGNATURE\" (issuing root not trusted), \"CERT_HAS_EXPIRED\" (also reported in \"days_until_expiry\"). This is the authoritative chain-trust signal — the issuer and subject fields alone cannot detect an untrusted root.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "chain_depth": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Number of certificates the server sent, counting the leaf. Null when the runtime does not expose the issuer chain — read \"chain_depth_unavailable_reason\" in that case. Not a self-signed indicator: use \"authorization_error\" for that."
+ },
+ "chain_depth_unavailable_reason": {
+ "description": "Why \"chain_depth\" is null, or null when a depth was measured. Absence of a depth is a runtime limitation, not a finding about the certificate.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "days_until_expiry": {
+ "description": "Days remaining until certificate expiry. Negative = already expired.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "hostname_verification_error": {
+ "description": "Node's hostname-verification message when the requested domain is not covered by the certificate's CN or SANs (e.g. \"Hostname/IP does not match certificate's altnames: …\"), or null when the hostname is covered. A non-null value means ordinary clients reject this certificate for this hostname; compare against the \"san\" list to see what it does cover.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "issuer": {
+ "description": "Issuer common name.",
+ "type": "string"
+ },
+ "san": {
+ "description": "Subject Alternative Names covered by this certificate.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "serial": {
+ "description": "Certificate serial number.",
+ "type": "string"
+ },
+ "subject": {
+ "description": "Certificate subject CN.",
+ "type": "string"
+ },
+ "valid_from": {
+ "description": "ISO 8601 UTC timestamp of certificate validity start.",
+ "type": "string"
+ },
+ "valid_until": {
+ "description": "ISO 8601 UTC timestamp of certificate expiry.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "subject",
+ "san",
+ "issuer",
+ "valid_from",
+ "valid_until",
+ "days_until_expiry",
+ "chain_depth",
+ "chain_depth_unavailable_reason",
+ "hostname_verification_error",
+ "authorization_error",
+ "serial"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / results / items / properties / error / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / results / items / properties / error / typeAdded value: +[
+ "string",
+ "null"
+]devops_check_dns6 fields changedOutput schema / properties / results / items / properties / error / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / results / items / properties / error / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / results / items / properties / records_source / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / results / items / properties / records_source / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / results / items / properties / resolver_results / items / properties / error / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / results / items / properties / resolver_results / items / properties / error / typeAdded value: +[
+ "string",
+ "null"
+]devops_get_incidents12 fields changedOutput schema / properties / incidents / items / properties / duration_minutes / anyOfRemoved value: -[
- {
- "type": "number"
- },
- {
- "type": "null"
- }
-]Output schema / properties / incidents / items / properties / duration_minutes / typeAdded value: +[
+ "number",
+ "null"
+]Output schema / properties / incidents / items / properties / resolved_at / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / incidents / items / properties / resolved_at / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / incidents / items / properties / scheduled_for / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / incidents / items / properties / scheduled_for / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / incidents / items / properties / scheduled_until / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / incidents / items / properties / scheduled_until / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / incidents / items / properties / shortlink / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / incidents / items / properties / shortlink / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / incidents / items / properties / started_at / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / incidents / items / properties / started_at / typeAdded value: +[
+ "string",
+ "null"
+]devops_status_check4 fields changedOutput schema / properties / results / items / properties / active_incidents / items / properties / started_at / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / results / items / properties / active_incidents / items / properties / started_at / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / results / items / properties / all_components / items / properties / description / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / results / items / properties / all_components / items / properties / description / typeAdded value: +[
+ "string",
+ "null"
+]devops_suggest_action4 fields changedOutput schema / properties / diagnostics_summary / properties / incident_snippet / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / diagnostics_summary / properties / incident_snippet / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / vendor_category / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / vendor_category / typeAdded value: +[
+ "string",
+ "null"
+]devops_watch_stack4 fields changedOutput schema / properties / vendors / items / properties / active_incidents / items / properties / started_at / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / vendors / items / properties / active_incidents / items / properties / started_at / typeAdded value: +[
+ "string",
+ "null"
+]Output schema / properties / vendors / items / properties / all_components / items / properties / description / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / vendors / items / properties / all_components / items / properties / description / typeAdded value: +[
+ "string",
+ "null"
+]devops_check_certs6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "results"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `invalid_domain`: A domain string contains a protocol prefix or invalid characters. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "invalid_domain"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "results"
-]devops_check_dns6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "results"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `invalid_domain`: A domain string contains a protocol prefix or invalid format. `target_blocked`: A resolver is a private, loopback, or otherwise non-public address, or is not an IP literal at all. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "invalid_domain",
+ "target_blocked"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "results"
-]devops_get_incidents6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "vendor",
+ "name",
+ "incidents",
+ "total_returned",
+ "statuspage_url"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `vendor_not_found`: Vendor slug not in registry and input is not a valid URL. `target_blocked`: A raw URL resolves to a private, loopback, or cloud-metadata address. `statuspage_unavailable`: The vendor's status API returned an error or timed out. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "vendor_not_found",
+ "target_blocked",
+ "statuspage_unavailable"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "vendor",
- "name",
- "incidents",
- "total_returned",
- "statuspage_url"
-]devops_list_vendors6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "vendors",
+ "total",
+ "categories"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode.",
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "vendors",
- "total",
- "categories"
-]devops_status_check6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "results",
+ "summary"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `vendor_not_found`: No requested vendor could be checked and the first failure was a slug that matches no registry entry and is not a valid URL. `target_blocked`: No requested vendor could be checked and the first failure was a raw URL resolving to a private, loopback, or cloud-metadata address. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "vendor_not_found",
+ "target_blocked"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "results",
- "summary"
-]devops_suggest_action6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "vendor",
+ "vendor_category",
+ "guidance",
+ "diagnostics_summary",
+ "nextToolSuggestions"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode.",
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "vendor",
- "vendor_category",
- "guidance",
- "diagnostics_summary",
- "nextToolSuggestions"
-]devops_watch_stack10 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / stack_name / descriptionPrevious value: -"Name for this vendor stack. Defaults to \"default\". Use distinct names to manage multiple stacks (e.g., \"production\", \"data-layer\")."New value: +"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."Input schema / properties / stack_name / maxLengthAdded value: +64Input schema / properties / stack_name / minLengthAdded value: +1Input schema / properties / stack_name / patternAdded value: +"^[a-zA-Z0-9_-]+([./][a-zA-Z0-9_-]+)*$"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "stack_name",
+ "health",
+ "summary",
+ "vendors",
+ "stack_persisted",
+ "omitted_vendors",
+ "checked_at"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `no_stack`: No vendors provided and no saved stack found for stack_name. `vendor_not_found`: No vendor in the stack could be checked and the first failure was a slug that is not in the registry and is not a valid URL. `target_blocked`: No vendor in the stack could be checked and the first failure was a raw URL resolving to a private, loopback, or cloud-metadata address. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "no_stack",
+ "vendor_not_found",
+ "target_blocked"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "stack_name",
- "health",
- "summary",
- "vendors",
- "stack_persisted",
- "omitted_vendors",
- "checked_at"
-]devops_check_dns4 fields changedOutput schema / properties / results / items / properties / records / descriptionPrevious value: -"Resolved records from a single resolver, keyed by record type (A, AAAA, CNAME, MX, TXT, NS). Taken from the primary resolver (first in \"resolvers\"), or from the first resolver that returned records when the primary returned none. Read \"records_source\" for which resolver these came from, and \"resolver_results\" for the full per-resolver picture."New value: +"Resolved records from a single resolver, keyed by record type (A, AAAA, CNAME, MX, TXT, NS). Taken from the primary resolver (first in \"resolvers\"), or from the first resolver that returned records when the primary returned none. Read \"records_source\" for which resolver these came from, and \"resolver_results\" for the full per-resolver picture. This is also the reference set the per-resolver answers are reported against: a resolver that returned exactly these values for a type names it in \"records_same_as_domain\" rather than repeating them."Output schema / properties / results / items / properties / resolver_results / items / properties / records / descriptionPrevious value: -"Records returned by this resolver, keyed by type."New value: +"Records returned by this resolver, keyed by type — carrying only the types whose values differ from the domain-level \"records\" set. A type this resolver answered identically is named in \"records_same_as_domain\" instead of repeated here. A requested type in neither place returned nothing from this resolver; \"status_by_type\" says why."Output schema / properties / results / items / properties / resolver_results / items / properties / records_same_as_domainAdded value: +{
+ "description": "Record types this resolver answered with exactly the domain-level \"records\" values, omitted from \"records\" above rather than duplicated. Read their values from the domain-level set. Resolvers agreeing is the common case, so this list is usually where most of the answer is.",
+ "items": {
+ "description": "A record type answered exactly as the domain-level set.",
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / results / items / properties / resolver_results / items / requiredPrevious value: -[
- "resolver",
- "latency_ms",
- "records",
- "status",
- "status_by_type",
- "error"
-]New value: +[
+ "resolver",
+ "latency_ms",
+ "records",
+ "records_same_as_domain",
+ "status",
+ "status_by_type",
+ "error"
+]devops_get_incidents1 field changedOutput schema / properties / notice / descriptionPrevious value: -"Plain-language explanation of this result — how to page onward, why it came back empty (filter the backend cannot satisfy, or an offset past the end), or that the vendor feed capped the history. Absent when the result needs no explanation."New value: +"Plain-language explanation of this result — how to page onward, why it came back empty (the vendor currently publishes nothing at all, a filter the backend cannot satisfy, or an offset past the end), or that the vendor feed capped the history. Absent when the result needs no explanation."devops_status_check6 fields changedOutput schema / properties / results / items / properties / degraded_components / descriptionPrevious value: -"Components not in operational state. Empty when all clear."New value: +"Every component not in an operational state, uncapped — a vendor with a large edge-node fleet routinely publishes dozens. Includes in-progress maintenance windows (status under_maintenance) alongside genuine outages; read status to tell a planned window from a fault. Empty when all clear."Output schema / properties / results / items / properties / indicator / descriptionPrevious value: -"Overall health indicator: none = all clear, minor = some degradation, major = significant outage, critical = complete outage."New value: +"Overall health indicator: none = all clear, minor = some degradation, major = significant outage, critical = complete outage, maintenance = scheduled window in progress, planned rather than a fault."Output schema / properties / results / items / properties / indicator / enumPrevious value: -[
- "none",
- "minor",
- "major",
- "critical"
-]New value: +[
+ "none",
+ "minor",
+ "major",
+ "critical",
+ "maintenance"
+]Output schema / properties / summary / descriptionPrevious value: -"Aggregate health counts across all checked vendors. Buckets partition the batch: operational + degraded + down + unavailable = total."New value: +"Aggregate health counts across all checked vendors. Buckets partition the batch: operational + degraded + down + maintenance + unavailable = total."Output schema / properties / summary / properties / maintenanceAdded value: +{
+ "description": "Vendors with indicator = maintenance — in a scheduled window the vendor published. Counted apart from degraded and down, which are faults.",
+ "type": "number"
+}Output schema / properties / summary / requiredPrevious value: -[
- "total",
- "operational",
- "degraded",
- "down",
- "unavailable"
-]New value: +[
+ "total",
+ "operational",
+ "degraded",
+ "down",
+ "maintenance",
+ "unavailable"
+]devops_suggest_action2 fields changedInput schema / properties / vendor_indicator / enumPrevious value: -[
- "none",
- "minor",
- "major",
- "critical"
-]New value: +[
+ "none",
+ "minor",
+ "major",
+ "critical",
+ "maintenance"
+]Output schema / properties / diagnostics_summary / properties / vendor_indicator / anyOfPrevious value: -[
- {
- "enum": [
- "none",
- "minor",
- "major",
- "critical"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "enum": [
+ "none",
+ "minor",
+ "major",
+ "critical",
+ "maintenance"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]devops_watch_stack8 fields changedOutput schema / properties / health / descriptionPrevious value: -"Aggregate health rollup: all_operational = everything clear, degraded = at least one minor issue, partial_outage = at least one major issue, major_outage = at least one critical outage, unknown = at least one vendor could not be checked (unresolvable entry, blocked target, or failed fetch) and no checked vendor reported a worse issue. Never all_operational when any vendor errored."New value: +"Aggregate health rollup: all_operational = everything clear, maintenance = at least one vendor in a scheduled window and nothing worse open, degraded = at least one minor issue, partial_outage = at least one major issue, major_outage = at least one critical outage, unknown = at least one vendor could not be checked (unresolvable entry, blocked target, or failed fetch) and no checked vendor reported a worse issue. Never all_operational when any vendor errored or is in a window."Output schema / properties / health / enumPrevious value: -[
- "all_operational",
- "degraded",
- "partial_outage",
- "major_outage",
- "unknown"
-]New value: +[
+ "all_operational",
+ "maintenance",
+ "degraded",
+ "partial_outage",
+ "major_outage",
+ "unknown"
+]Output schema / properties / summary / descriptionPrevious value: -"Aggregate health counts across all checked vendors. Buckets partition the stack: operational + degraded + down + unavailable = total."New value: +"Aggregate health counts across all checked vendors. Buckets partition the stack: operational + degraded + down + maintenance + unavailable = total."Output schema / properties / summary / properties / maintenanceAdded value: +{
+ "description": "Vendors with indicator = maintenance — in a scheduled window the vendor published. Counted apart from degraded and down, which are faults.",
+ "type": "number"
+}Output schema / properties / summary / requiredPrevious value: -[
- "total",
- "operational",
- "degraded",
- "down",
- "unavailable"
-]New value: +[
+ "total",
+ "operational",
+ "degraded",
+ "down",
+ "maintenance",
+ "unavailable"
+]Output schema / properties / vendors / items / properties / degraded_components / descriptionPrevious value: -"Components not in operational state. Empty when all clear."New value: +"Every component not in an operational state, uncapped — a vendor with a large edge-node fleet routinely publishes dozens. Includes in-progress maintenance windows (status under_maintenance) alongside genuine outages; read status to tell a planned window from a fault. Empty when all clear."Output schema / properties / vendors / items / properties / indicator / descriptionPrevious value: -"Overall health indicator: none = all clear, minor = some degradation, major = significant outage, critical = complete outage."New value: +"Overall health indicator: none = all clear, minor = some degradation, major = significant outage, critical = complete outage, maintenance = scheduled window in progress, planned rather than a fault."Output schema / properties / vendors / items / properties / indicator / enumPrevious value: -[
- "none",
- "minor",
- "major",
- "critical"
-]New value: +[
+ "none",
+ "minor",
+ "major",
+ "critical",
+ "maintenance"
+]devops_get_incidents1 field changedInput schema / properties / filter / descriptionPrevious value: -"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\" publishes currently-open events only (never resolved, no maintenance windows) and \"slack\" publishes no maintenance windows. An empty result names which case applied."New value: +"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\" publishes currently-open events only (never resolved, no maintenance windows), and \"gcp\" and \"slack\" publish no maintenance windows. An empty result names which case applied."devops_list_vendors1 field changedOutput schema / properties / vendors / items / properties / statuspage_url / descriptionPrevious value: -"Status page base URL — the Statuspage API base for Statuspage-backed vendors, the public status page URL for adapter-backed vendors (aws, gitlab, slack, neon)."New value: +"Status page base URL — the Statuspage API base for Statuspage-backed vendors, the public status page URL for adapter-backed vendors (aws, gcp, gitlab, slack, neon, redis-cloud)."devops_check_certs3 fields changedOutput schema / properties / results / items / properties / cert / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "chain_depth": {
- "description": "Number of certificates in the chain (1 = self-signed).",
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- "days_until_expiry": {
- "description": "Days remaining until certificate expiry. Negative = already expired.",
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- "issuer": {
- "description": "Issuer common name.",
- "type": "string"
- },
- "san": {
- "description": "Subject Alternative Names covered by this certificate.",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "serial": {
- "description": "Certificate serial number.",
- "type": "string"
- },
- "subject": {
- "description": "Certificate subject CN.",
- "type": "string"
- },
- "valid_from": {
- "description": "ISO 8601 UTC timestamp of certificate validity start.",
- "type": "string"
- },
- "valid_until": {
- "description": "ISO 8601 UTC timestamp of certificate expiry.",
- "type": "string"
- }
- },
- "required": [
- "subject",
- "san",
- "issuer",
- "valid_from",
- "valid_until",
- "days_until_expiry",
- "chain_depth",
- "serial"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "authorization_error": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "OpenSSL chain-verification code when the certificate chain does not validate against the system trust store, or null when it validates. Common values: \"DEPTH_ZERO_SELF_SIGNED_CERT\" (self-signed leaf), \"SELF_SIGNED_CERT_IN_CHAIN\" / \"UNABLE_TO_VERIFY_LEAF_SIGNATURE\" (issuing root not trusted), \"CERT_HAS_EXPIRED\" (also reported in \"days_until_expiry\"). This is the authoritative chain-trust signal — the issuer and subject fields alone cannot detect an untrusted root."
+ },
+ "chain_depth": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Number of certificates the server sent, counting the leaf. Null when the runtime does not expose the issuer chain — read \"chain_depth_unavailable_reason\" in that case. Not a self-signed indicator: use \"authorization_error\" for that."
+ },
+ "chain_depth_unavailable_reason": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Why \"chain_depth\" is null, or null when a depth was measured. Absence of a depth is a runtime limitation, not a finding about the certificate."
+ },
+ "days_until_expiry": {
+ "description": "Days remaining until certificate expiry. Negative = already expired.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "hostname_verification_error": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Node's hostname-verification message when the requested domain is not covered by the certificate's CN or SANs (e.g. \"Hostname/IP does not match certificate's altnames: …\"), or null when the hostname is covered. A non-null value means ordinary clients reject this certificate for this hostname; compare against the \"san\" list to see what it does cover."
+ },
+ "issuer": {
+ "description": "Issuer common name.",
+ "type": "string"
+ },
+ "san": {
+ "description": "Subject Alternative Names covered by this certificate.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "serial": {
+ "description": "Certificate serial number.",
+ "type": "string"
+ },
+ "subject": {
+ "description": "Certificate subject CN.",
+ "type": "string"
+ },
+ "valid_from": {
+ "description": "ISO 8601 UTC timestamp of certificate validity start.",
+ "type": "string"
+ },
+ "valid_until": {
+ "description": "ISO 8601 UTC timestamp of certificate expiry.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "subject",
+ "san",
+ "issuer",
+ "valid_from",
+ "valid_until",
+ "days_until_expiry",
+ "chain_depth",
+ "chain_depth_unavailable_reason",
+ "hostname_verification_error",
+ "authorization_error",
+ "serial"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / results / items / properties / flags / descriptionPrevious value: -"Human-readable warnings and issues found: \"expires in 12 days\", \"TLS 1.1 in use\", \"self-signed certificate\", \"HSTS present\", etc."New value: +"Human-readable warnings and issues found: \"Expires in 12 days (warning)\", \"Certificate expired 40 days ago\", \"Hostname mismatch — the certificate does not cover api.example.com; clients will reject it\", \"Certificate chain not trusted (SELF_SIGNED_CERT_IN_CHAIN); clients will reject it\", \"Self-signed certificate\", \"Insecure TLS version in use: TLSv1.1\", \"HSTS present\" / \"HSTS not configured\"."Output schema / properties / results / items / properties / status / descriptionPrevious value: -"Overall status: ok, warning (< 30 days), critical (< 7 days or insecure TLS), or error (connection failed)."New value: +"Overall status. \"critical\" — the certificate expires in < 7 days or has already expired, the hostname is not covered by the certificate, chain verification failed (self-signed or untrusted root), or an insecure TLS version was negotiated; every one of these is rejected by ordinary clients. \"warning\" — expires in < 30 days. \"ok\" — none of the above. \"error\" — the connection failed and no certificate was retrieved."devops_check_dns17 fields changedOutput schema / properties / results / items / properties / error / descriptionPrevious value: -"Overall error message if the domain could not be queried at all."New value: +"Set only when the domain could not be queried at all — every resolver failed and none returned records. Each failing resolver is named with its own outcome (\"8.8.8.8: SERVFAIL on A; 1.1.1.1: NXDOMAIN on A\") so a split result stays visible. Null when at least one resolver answered; per-resolver failures are still in \"resolver_results\" and \"flags\"."Output schema / properties / results / items / properties / flags / descriptionPrevious value: -"Human-readable observations: \"propagation mismatch on A records\", \"no MX records found\", \"CNAME detected — further records resolve via the CNAME target\", etc."New value: +"Human-readable observations that need attention: \"NXDOMAIN from 8.8.8.8, 1.1.1.1 on A, MX — the domain does not exist …\", \"Partial resolution on A records — 9.9.9.9 (nodata) returned nothing while 8.8.8.8 answered\", \"No MX records found\", \"CNAME detected — further records resolve via the CNAME target\". A value_variation disagreement is not flagged here — it is reported in \"propagation_discrepancies\" because it is normal for geo-steered domains."Output schema / properties / results / items / properties / propagation_discrepancies / descriptionPrevious value: -"Record types where resolvers returned different values. Empty when all resolvers agree."New value: +"Record types where resolvers returned different answers, each labelled by \"kind\". Empty when all resolvers agree."Output schema / properties / results / items / properties / propagation_discrepancies / items / descriptionPrevious value: -"A record type where resolvers returned different values."New value: +"A record type where resolvers returned different answers."Output schema / properties / results / items / properties / propagation_discrepancies / items / properties / kindAdded value: +{
+ "description": "What the disagreement is. \"partial_resolution\" = at least one resolver returned records and at least one returned nothing; this is the signal worth investigating (in-flight propagation, a broken resolver, or a partial delegation) — read \"status_by_resolver\" for why each empty resolver was empty. \"value_variation\" = every resolver answered but with different values; this is the expected steady state for anycast and geo-steered domains such as CDN-fronted hostnames, and is also consistent with an in-flight DNS change. Neither value asserts a cause on its own.",
+ "enum": [
+ "value_variation",
+ "partial_resolution"
+ ],
+ "type": "string"
+}Output schema / properties / results / items / properties / propagation_discrepancies / items / properties / record_type / descriptionPrevious value: -"The DNS record type with differing values."New value: +"The DNS record type resolvers disagreed on."Output schema / properties / results / items / properties / propagation_discrepancies / items / properties / resolvers_agree / descriptionPrevious value: -"False when resolvers returned different values."New value: +"Always false — an entry only exists when resolvers disagreed."Output schema / properties / results / items / properties / propagation_discrepancies / items / properties / status_by_resolverAdded value: +{
+ "additionalProperties": {
+ "enum": [
+ "ok",
+ "nodata",
+ "nxdomain",
+ "servfail",
+ "refused",
+ "timeout",
+ "error"
+ ],
+ "type": "string"
+ },
+ "description": "Outcome for this record type per resolver IP address — explains an empty entry in \"values_by_resolver\" as nodata, nxdomain, servfail, timeout, refused, or error.",
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+}Output schema / properties / results / items / properties / propagation_discrepancies / items / properties / values_by_resolver / descriptionPrevious value: -"Values reported per resolver IP address."New value: +"Values reported per resolver IP address. An empty array means that resolver returned no records of this type."Output schema / properties / results / items / properties / propagation_discrepancies / items / requiredPrevious value: -[
- "record_type",
- "resolvers_agree",
- "values_by_resolver"
-]New value: +[
+ "record_type",
+ "resolvers_agree",
+ "kind",
+ "values_by_resolver",
+ "status_by_resolver"
+]Output schema / properties / results / items / properties / records / descriptionPrevious value: -"Resolved records from the primary resolver (first in list). Keyed by record type (A, AAAA, CNAME, MX, TXT, NS)."New value: +"Resolved records from a single resolver, keyed by record type (A, AAAA, CNAME, MX, TXT, NS). Taken from the primary resolver (first in \"resolvers\"), or from the first resolver that returned records when the primary returned none. Read \"records_source\" for which resolver these came from, and \"resolver_results\" for the full per-resolver picture."Output schema / properties / results / items / properties / records_sourceAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Resolver IP whose answers populated \"records\", or null when no resolver was queried."
+}Output schema / properties / results / items / properties / resolver_results / items / properties / error / descriptionPrevious value: -"Error message if this resolver failed, or null on success."New value: +"Failure summary for this resolver in the form \"SERVFAIL on A, MX\", or null when every requested type either resolved or returned nodata. Nodata is never reported as an error — it is a valid DNS answer."Output schema / properties / results / items / properties / resolver_results / items / properties / statusAdded value: +{
+ "description": "Headline outcome for this resolver: \"ok\" when any requested record type resolved, otherwise the most actionable failure across the requested types (servfail, timeout, refused, error, nxdomain, nodata — in that order). Read \"status_by_type\" for the per-record-type detail.",
+ "enum": [
+ "ok",
+ "nodata",
+ "nxdomain",
+ "servfail",
+ "refused",
+ "timeout",
+ "error"
+ ],
+ "type": "string"
+}Output schema / properties / results / items / properties / resolver_results / items / properties / status_by_typeAdded value: +{
+ "additionalProperties": {
+ "enum": [
+ "ok",
+ "nodata",
+ "nxdomain",
+ "servfail",
+ "refused",
+ "timeout",
+ "error"
+ ],
+ "type": "string"
+ },
+ "description": "Outcome for each requested record type, keyed by type. \"ok\" = records returned; \"nodata\" = the domain exists but has no record of this type; \"nxdomain\" = the domain does not exist (check for a typo, an expired registration, or a missing delegation); \"servfail\" = the resolver could not complete the query, commonly a DNSSEC validation failure; \"refused\" = the resolver declined; \"timeout\" = no answer within timeout_ms; \"error\" = any other failure, described in \"error\".",
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+}Output schema / properties / results / items / properties / resolver_results / items / requiredPrevious value: -[
- "resolver",
- "latency_ms",
- "records",
- "error"
-]New value: +[
+ "resolver",
+ "latency_ms",
+ "records",
+ "status",
+ "status_by_type",
+ "error"
+]Output schema / properties / results / items / requiredPrevious value: -[
- "domain",
- "records",
- "resolver_results",
- "propagation_discrepancies",
- "flags",
- "error"
-]New value: +[
+ "domain",
+ "records",
+ "records_source",
+ "resolver_results",
+ "propagation_discrepancies",
+ "flags",
+ "error"
+]devops_get_incidents5 fields changedInput schema / properties / filter / descriptionPrevious value: -"all: incidents plus scheduled maintenances. active: only incidents with status investigating/identified/monitoring. resolved: only fully resolved incidents. scheduled: only scheduled maintenance windows."New value: +"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\" publishes currently-open events only (never resolved, no maintenance windows) and \"slack\" publishes no maintenance windows. An empty result names which case applied."Input schema / properties / offset / descriptionPrevious value: -"Number of matching incidents to skip before applying limit, for paging through history. 0 (default) returns the most recent page; a truncated result names the next offset to use."New value: +"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."Output schema / properties / nextOffsetAdded value: +{
+ "description": "The offset to pass on the next call to continue from where this page stopped, already computed as offset + the number returned. Present only when truncated — its absence means this page reached the end of what the filter matched.",
+ "type": "number"
+}Output schema / properties / noticeAdded value: +{
+ "description": "Plain-language explanation of this result — how to page onward, why it came back empty (filter the backend cannot satisfy, or an offset past the end), or that the vendor feed capped the history. Absent when the result needs no explanation.",
+ "type": "string"
+}Output schema / properties / upstreamCeilingAdded value: +{
+ "description": "Maximum incidents the vendor's own status API serves in one fetch, present only when that ceiling was reached on this call. It bounds the history independently of limit and offset: incidents older than the oldest one returned cannot be fetched at any offset, only browsed on the vendor status page. Absent when the vendor feed is unbounded or returned less than its ceiling.",
+ "type": "number"
+}devops_status_check1 field changedOutput schema / properties / noticeAdded value: +{
+ "description": "Plain-language explanation of the capped component lists — how many components were omitted and how to reach them (component_filter to target one, component_limit to raise the cap). Present only when truncated.",
+ "type": "string"
+}devops_watch_stack1 field changedOutput schema / properties / noticeAdded value: +{
+ "description": "Plain-language explanation of the capped component lists — how many components were omitted and how to reach them (component_filter to target one, component_limit to raise the cap). Present only when truncated.",
+ "type": "string"
+}devops_status_check13 fields changedInput schema / properties / component_filterAdded value: +{
+ "description": "Case-insensitive substring matched against component names in detailed mode (e.g., \"api\" to check just the API components). Applied before component_limit, so it is the way to reach a component that the cap would otherwise omit. Ignored in summary mode.",
+ "type": "string"
+}Input schema / properties / component_limitAdded value: +{
+ "default": 50,
+ "description": "Maximum components returned per vendor in detailed mode (1-500). 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.",
+ "maximum": 500,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / mode / descriptionPrevious value: -"summary: indicator + degraded components + active incidents only. detailed: adds full component list and scheduled maintenance windows."New value: +"summary: indicator + degraded components + active incidents only. detailed: adds the component list and scheduled maintenance windows."Output schema / properties / capAdded value: +{
+ "description": "The per-vendor component_limit that was applied. Present only when truncated.",
+ "type": "number"
+}Output schema / properties / results / items / properties / all_components / descriptionPrevious value: -"All components including operational ones. Present in detailed mode only."New value: +"Components including operational ones, capped at component_limit per vendor and narrowed by component_filter when given. Present in detailed mode only."Output schema / properties / results / items / properties / all_components_totalAdded value: +{
+ "description": "Components matching component_filter for this vendor before the component_limit cap. Larger than the length of all_components when this vendor was capped. Present in detailed mode only.",
+ "type": "number"
+}Output schema / properties / shownAdded value: +{
+ "description": "Components returned across all vendors. Present only when truncated.",
+ "type": "number"
+}Output schema / properties / summary / descriptionPrevious value: -"Aggregate health counts across all checked vendors."New value: +"Aggregate health counts across all checked vendors. Buckets partition the batch: operational + degraded + down + unavailable = total."Output schema / properties / summary / properties / operational / descriptionPrevious value: -"Vendors with indicator = none."New value: +"Vendors with indicator = none and no error."Output schema / properties / summary / properties / unavailableAdded value: +{
+ "description": "Vendors that could not be checked (carry an error) — unresolvable slug, blocked target, or failed status fetch. Counted as unknown, never operational.",
+ "type": "number"
+}Output schema / properties / summary / requiredPrevious value: -[
- "total",
- "operational",
- "degraded",
- "down"
-]New value: +[
+ "total",
+ "operational",
+ "degraded",
+ "down",
+ "unavailable"
+]Output schema / properties / totalCountAdded value: +{
+ "description": "Components matching component_filter across all vendors before the cap. Present only when truncated.",
+ "type": "number"
+}Output schema / properties / truncatedAdded value: +{
+ "description": "True when at least one vendor's component list was capped at component_limit. Absent when nothing was capped.",
+ "type": "boolean"
+}devops_watch_stack15 fields changedInput schema / properties / component_filterAdded value: +{
+ "description": "Case-insensitive substring matched against component names in detailed mode (e.g., \"api\" to check just the API components). Applied before component_limit, so it is the way to reach a component that the cap would otherwise omit. Ignored in summary mode.",
+ "type": "string"
+}Input schema / properties / component_limitAdded value: +{
+ "default": 50,
+ "description": "Maximum components returned per vendor in detailed mode (1-500). 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.",
+ "maximum": 500,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / mode / descriptionPrevious value: -"summary: indicator + degraded components + active incidents. detailed: adds full component lists and maintenance windows."New value: +"summary: indicator + degraded components + active incidents. detailed: adds component lists and maintenance windows."Output schema / properties / capAdded value: +{
+ "description": "The per-vendor component_limit that was applied. Present only when truncated.",
+ "type": "number"
+}Output schema / properties / health / descriptionPrevious value: -"Aggregate health rollup: all_operational = everything clear, degraded = at least one minor issue, partial_outage = at least one major issue, major_outage = at least one critical outage, unknown = at least one vendor could not be checked (fetch error) and no checked vendor reported a worse issue. Never all_operational when any vendor errored."New value: +"Aggregate health rollup: all_operational = everything clear, degraded = at least one minor issue, partial_outage = at least one major issue, major_outage = at least one critical outage, unknown = at least one vendor could not be checked (unresolvable entry, blocked target, or failed fetch) and no checked vendor reported a worse issue. Never all_operational when any vendor errored."Output schema / properties / omitted_vendorsAdded value: +{
+ "description": "Entries that could not be resolved or whose URL was blocked; they still appear in vendors[] with an error. A call that saved the stack left them out of the write; a call that reused a saved stack leaves them in it until you re-provide the vendors list. Empty when every entry resolved.",
+ "items": {
+ "description": "A vendor entry that cannot be part of a usable stack.",
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / shownAdded value: +{
+ "description": "Components returned across the stack. Present only when truncated.",
+ "type": "number"
+}Output schema / properties / stack_persisted / descriptionPrevious value: -"True when the vendor list was saved to state on this call."New value: +"True when the vendor list was saved to state on this call. Only the vendors that resolved are saved — see omitted_vendors."Output schema / properties / summary / properties / operational / descriptionPrevious value: -"Vendors with indicator = none and no fetch error."New value: +"Vendors with indicator = none and no error."Output schema / properties / summary / properties / unavailable / descriptionPrevious value: -"Vendors whose status could not be fetched (carry an error). Counted as unknown — never operational."New value: +"Vendors that could not be checked (carry an error) — unresolvable entry, blocked target, or failed status fetch. Counted as unknown, never operational."Output schema / properties / totalCountAdded value: +{
+ "description": "Components matching component_filter across the stack before the cap. Present only when truncated.",
+ "type": "number"
+}Output schema / properties / truncatedAdded value: +{
+ "description": "True when at least one vendor's component list was capped at component_limit. Absent when nothing was capped.",
+ "type": "boolean"
+}Output schema / properties / vendors / items / properties / all_components / descriptionPrevious value: -"All components including operational ones. Present in detailed mode only."New value: +"Components including operational ones, capped at component_limit per vendor and narrowed by component_filter when given. Present in detailed mode only."Output schema / properties / vendors / items / properties / all_components_totalAdded value: +{
+ "description": "Components matching component_filter for this vendor before the component_limit cap. Larger than the length of all_components when this vendor was capped. Present in detailed mode only.",
+ "type": "number"
+}Output schema / requiredPrevious value: -[
- "stack_name",
- "health",
- "summary",
- "vendors",
- "stack_persisted",
- "checked_at"
-]New value: +[
+ "stack_name",
+ "health",
+ "summary",
+ "vendors",
+ "stack_persisted",
+ "omitted_vendors",
+ "checked_at"
+]devops_check_dns2 fields changedInput schema / properties / resolvers / descriptionPrevious value: -"Resolver IP addresses to query. Defaults to Google (8.8.8.8), Cloudflare (1.1.1.1), and Quad9 (9.9.9.9). Add custom resolvers to check internal DNS or test resolver-specific behavior."New value: +"Resolver IP addresses to query. Defaults to Google (8.8.8.8), Cloudflare (1.1.1.1), and Quad9 (9.9.9.9). Add custom resolvers to test resolver-specific behavior. 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."Input schema / properties / resolvers / items / descriptionPrevious value: -"A resolver IP address (e.g., \"8.8.8.8\")."New value: +"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."devops_status_check3 fields changedOutput schema / properties / results / items / properties / active_incidents / items / properties / impact / descriptionPrevious value: -"Severity level: none = informational, minor = degraded performance, major = partial outage, critical = full outage."New value: +"Severity level: none = informational, minor = degraded performance, major = partial outage, critical = full outage, maintenance = scheduled window folded into incident history."Output schema / properties / results / items / properties / active_incidents / items / properties / impact / enumPrevious value: -[
- "none",
- "minor",
- "major",
- "critical"
-]New value: +[
+ "none",
+ "minor",
+ "major",
+ "critical",
+ "maintenance"
+]Output schema / properties / results / items / properties / error / descriptionPrevious value: -"Fetch error message. Absent when the vendor was fetched successfully."New value: +"Why this vendor could not be checked — unreachable status API, timeout, non-2xx, or a response that is not a Statuspage payload. Reported here rather than thrown so one bad vendor does not fail the batch. Absent when the vendor was fetched successfully."devops_watch_stack3 fields changedOutput schema / properties / vendors / items / properties / active_incidents / items / properties / impact / descriptionPrevious value: -"Severity level: none = informational, minor = degraded performance, major = partial outage, critical = full outage."New value: +"Severity level: none = informational, minor = degraded performance, major = partial outage, critical = full outage, maintenance = scheduled window folded into incident history."Output schema / properties / vendors / items / properties / active_incidents / items / properties / impact / enumPrevious value: -[
- "none",
- "minor",
- "major",
- "critical"
-]New value: +[
+ "none",
+ "minor",
+ "major",
+ "critical",
+ "maintenance"
+]Output schema / properties / vendors / items / properties / error / descriptionPrevious value: -"Fetch error message. Absent when the vendor was fetched successfully."New value: +"Why this vendor could not be checked — unreachable status API, timeout, non-2xx, or a response that is not a Statuspage payload. Reported here rather than thrown so one bad vendor does not fail the batch. Absent when the vendor was fetched successfully."devops_get_incidents3 fields changedInput schema / properties / limit / descriptionPrevious value: -"Maximum incidents to return. Vendor status APIs return at most ~50 recent entries per call. Use a lower limit for recent-history queries."New value: +"Maximum incidents to return per call (1–50). Page through longer history with offset rather than raising this."Input schema / properties / offsetAdded value: +{
+ "default": 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 names the next offset to use.",
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+}Output schema / properties / totalCountAdded value: +{
+ "description": "Total incidents matching the filter, across all pages, before offset/limit windowing. Present only when the result was truncated.",
+ "type": "number"
+}devops_check_certs2 fields changedInput schema / properties / domains / items / minLengthAdded value: +1Input schema / properties / domains / items / patternRemoved value: -"^[a-zA-Z0-9]([a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(\\.[a-zA-Z0-9]([a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$"devops_suggest_action1 field changedOutput schema / properties / diagnostics_summary / properties / incident_snippet / descriptionPrevious value: -"First 200 characters of incident_summary truncated for context, or null when not provided."New value: +"The incident_summary input echoed in full for context, or null when not provided."devops_watch_stack6 fields changedOutput schema / properties / health / descriptionPrevious value: -"Aggregate health rollup: all_operational = everything clear, degraded = at least one minor issue, partial_outage = at least one major issue, major_outage = at least one critical outage."New value: +"Aggregate health rollup: all_operational = everything clear, degraded = at least one minor issue, partial_outage = at least one major issue, major_outage = at least one critical outage, unknown = at least one vendor could not be checked (fetch error) and no checked vendor reported a worse issue. Never all_operational when any vendor errored."Output schema / properties / health / enumPrevious value: -[
- "all_operational",
- "degraded",
- "partial_outage",
- "major_outage"
-]New value: +[
+ "all_operational",
+ "degraded",
+ "partial_outage",
+ "major_outage",
+ "unknown"
+]Output schema / properties / summary / descriptionPrevious value: -"Aggregate health counts across all checked vendors."New value: +"Aggregate health counts across all checked vendors. Buckets partition the stack: operational + degraded + down + unavailable = total."Output schema / properties / summary / properties / operational / descriptionPrevious value: -"Vendors with indicator = none."New value: +"Vendors with indicator = none and no fetch error."Output schema / properties / summary / properties / unavailableAdded value: +{
+ "description": "Vendors whose status could not be fetched (carry an error). Counted as unknown — never operational.",
+ "type": "number"
+}Output schema / properties / summary / requiredPrevious value: -[
- "total",
- "operational",
- "degraded",
- "down"
-]New value: +[
+ "total",
+ "operational",
+ "degraded",
+ "down",
+ "unavailable"
+]devops_check_certs1 field changedInput schema / properties / timeout_ms / descriptionPrevious value: -"Connection timeout per domain in milliseconds. Increase for slow or geographically distant endpoints."New value: +"Connection timeout per domain in milliseconds. Defaults to the DEVOPS_STATUS_CERT_TIMEOUT_MS env var (5000 when unset). Increase for slow or geographically distant endpoints."devops_check_dns1 field changedInput schema / properties / timeout_ms / descriptionPrevious value: -"Query timeout per domain+resolver combination in milliseconds."New value: +"Query timeout per domain+resolver combination in milliseconds. Defaults to the DEVOPS_STATUS_DNS_TIMEOUT_MS env var (3000 when unset)."devops_get_incidents4 fields changedInput schema / properties / limit / descriptionPrevious value: -"Maximum incidents to return. Statuspage returns at most 50 per call. Use a lower limit for recent-history queries."New value: +"Maximum incidents to return. Vendor status APIs return at most ~50 recent entries per call. Use a lower limit for recent-history queries."Input schema / properties / vendor / descriptionPrevious value: -"Vendor slug (e.g., \"github\") or raw Statuspage base URL. Use devops_list_vendors to find slugs."New value: +"Vendor slug (e.g., \"github\", \"aws\") or raw Atlassian Statuspage base URL. Use devops_list_vendors to find slugs."Output schema / properties / incidents / items / properties / id / descriptionPrevious value: -"Unique incident identifier from Statuspage."New value: +"Unique incident identifier from the vendor's status API."Output schema / properties / statuspage_url / descriptionPrevious value: -"Statuspage base URL used."New value: +"Status page base URL used."devops_list_vendors1 field changedOutput schema / properties / vendors / items / properties / statuspage_url / descriptionPrevious value: -"Statuspage base URL used to fetch status data."New value: +"Status page base URL — the Statuspage API base for Statuspage-backed vendors, the public status page URL for adapter-backed vendors (aws, gitlab, slack, neon)."devops_status_check4 fields changedInput schema / properties / vendors / descriptionPrevious value: -"Vendor slugs from the built-in registry (e.g., \"github\", \"cloudflare\") or raw Statuspage base URLs. Mix freely. Use devops_list_vendors to discover available slugs."New value: +"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."Input schema / properties / vendors / items / descriptionPrevious value: -"A vendor slug (e.g., \"github\") or raw Statuspage base URL."New value: +"A vendor slug (e.g., \"github\") or raw Atlassian Statuspage base URL."Output schema / properties / results / items / properties / active_incidents / items / properties / id / descriptionPrevious value: -"Unique incident identifier from Statuspage."New value: +"Unique incident identifier from the vendor's status API."Output schema / properties / results / items / properties / statuspage_url / descriptionPrevious value: -"Statuspage base URL used for this vendor."New value: +"Status page base URL used for this vendor."devops_watch_stack4 fields changedInput schema / properties / vendors / descriptionPrevious value: -"Vendor slugs or raw Statuspage URLs. When provided, saves this list as the stack. When omitted, uses the previously saved list for stack_name."New value: +"Vendor slugs (e.g., \"github\", \"aws\") or raw Atlassian Statuspage base URLs. When provided, saves this list as the stack. When omitted, uses the previously saved list for stack_name."Input schema / properties / vendors / items / descriptionPrevious value: -"A vendor slug (e.g., \"github\") or raw Statuspage base URL."New value: +"A vendor slug (e.g., \"github\") or raw Atlassian Statuspage base URL."Output schema / properties / vendors / items / properties / active_incidents / items / properties / id / descriptionPrevious value: -"Unique incident identifier from Statuspage."New value: +"Unique incident identifier from the vendor's status API."Output schema / properties / vendors / items / properties / statuspage_url / descriptionPrevious value: -"Statuspage base URL used for this vendor."New value: +"Status page base URL used for this vendor."DNS, email auth, TLS, BGP/RPKI, WHOIS and subnet tools with plain-English fixes, plus webhook URLs.
Live cloud/SaaS outages, provider reliability and exploited CVEs from official status pages and CISA
Uptime checks, status pages, incidents, and maintenance for websites, APIs, DNS, and TCP.
Uptime checks, status pages, incidents, and maintenance for websites, APIs, DNS, and TCP.
Add one secure layer between your agents and this server.
