Vendor status pages, TLS cert inspection, DNS propagation checks, and incident-response playbooks.
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), cipher suite, and HSTS presence. 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". If a domain fails to connect at all, check devops_check_dns first — the name may not resolve.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | TLS port. Defaults to 443. Use 8443 or custom ports for non-standard HTTPS endpoints. | |
| domains | Yes | Domains to inspect. Do not include "https://" — pass the bare hostname. Up to 10 per call. | |
| timeout_ms | No | 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. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| results | No | Per-domain certificate inspection results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark this as readOnly, openWorld, and idempotent, but the description adds substantial behavioral context: the handshake completes even for broken certificates, failure modes are surfaced as specific fields (cert.hostname_verification_error, cert.authorization_error) with 'critical' status, and TLS 1.0/1.1 are flagged insecure. This goes far beyond the annotations and clarifies edge-case behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a dense paragraph where every clause adds value: it front-loads the core purpose, enumerates reported attributes, explains graceful handling of broken certs, and ends with a concrete fallback. There is no redundancy or filler; each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (certificate attributes, TLS versions, HSTS, chain trust), the description covers the full behavioral scope, including failure modes and how they are reported. An output schema exists but the description adds meaning to fields like hostname_verification_error and authorization_error. The fallback hint completes the contextual picture.
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, port, and timeout_ms with usage tips (e.g., 'Do not include https://'). The description adds no parameter-specific meaning beyond the schema; it mentions 'one or more domains' but that is already reflected in the schema's minItems. The baseline of 3 is appropriate since 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?
The description opens with a specific verb and resource ('Inspect SSL/TLS certificate health') and states it performs a real TLS handshake on any internet-accessible domain. It clearly distinguishes the tool's scope from siblings by noting it works without a vendor registry, and later points to devops_check_dns as an alternative for connection failures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly gives when to use the tool (any domain, no registry needed), what it reports, and when to fall back to a sibling ('If a domain fails to connect at all, check devops_check_dns first'). This is a clear, actionable usage guide that routes an agent to the correct sibling.
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), 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. Up to 10 per call. | |
| 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). 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. | |
| timeout_ms | No | Query timeout per domain+resolver combination in milliseconds. Defaults to the DEVOPS_STATUS_DNS_TIMEOUT_MS env var (3000 when unset). | |
| record_types | No | DNS record types to resolve. Defaults to A, AAAA, MX, and TXT. Add NS to check nameserver delegation. Add CNAME when investigating redirect chains. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| results | No | Per-domain DNS resolution results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so safety is covered. The description goes well beyond that by detailing output specifics: reports records found, resolution latency, and typed outcomes (nxdomain/servfail/nodata), plus explaining partial_resolution vs value_variation semantics. It also notes that resolver disagreements are reported without asserting cause. This is rich behavioral context that helps the agent set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but each sentence earns its place. It leads with the core action, then covers domain scope, output details, resolver-outcome semantics, and a sibling pairing. The structure is logical and front-loaded, with no redundant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, multiple resolvers, distinct outcomes), the description covers everything an agent needs: when to use it (any domain, no vendor registry), what it returns (records, latency, typed outcomes), how to interpret resolver disagreements, and a concrete pairing with devops_check_certs. The output schema exists but the description still adds value by explaining the meaning of outcomes, making the context complete.
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 every parameter (domains, resolvers, timeout_ms, record_types) is already documented in the schema with format details, defaults, and constraints. The description does not add parameter-specific meaning beyond the schema; it merely restates the record types in general and mentions the resolver comparison. This matches the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb-resource combination ('Resolve DNS records ... across multiple public resolvers and compare what each resolver returned'), which clearly distinguishes it from sibling tools like devops_status_check or devops_check_certs. It also explicitly names a complementary sibling (devops_check_certs) and explains the scope ('Works for any domain — no vendor registry required'). The purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit pairing condition: 'Pair with devops_check_certs when a domain resolves but TLS to it is failing.' It also states the tool works for any domain, implying no vendor prerequisites. While it doesn't enumerate exclusions against other siblings (e.g., devops_get_incidents), the one explicit alternative and the scope hint make when-to-use reasonably clear. It doesn't explicitly say when *not* to use it, so it's not a 5.
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 upcoming maintenance windows. Page through long histories with limit + offset — a truncated result discloses the total and returns the value to page with in nextOffset. Some vendor feeds cap their own history: when upstreamCeiling is present the vendor API returned everything it will serve, and older incidents are reachable only on the vendor status page, not at a higher offset. An empty result explains itself in notice.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum incidents to return per call (1–50). Page through longer history with offset rather than raising this. | |
| filter | No | 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. | 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. |
| Name | Required | Description |
|---|---|---|
| cap | No | The limit that was applied. 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 returned after applying the limit. Present only when truncated. |
| notice | No | 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. |
| vendor | No | Vendor slug or URL as provided. |
| incidents | No | Matching incidents. |
| truncated | No | True when more incidents matched than the limit returned. Absent when the result was not capped. |
| 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, 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, only browsed on the vendor status page. Absent when the vendor feed is unbounded or returned less than its ceiling. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, and idempotentHint, but the description adds significant behavioral detail beyond those: vendor-specific history caps (upstreamCeiling), pagination semantics (nextOffset), and self-explaining empty results via notice. This exceeds what annotations provide and is crucial for correct usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is about five sentences, each adding distinct value: purpose, filter usage, pagination, vendor ceiling, and empty-result behavior. It is front-loaded with the core action and structured logically without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are covered. The description covers all operational edge cases: vendor-specific filter availability, pagination truncation with nextOffset, upstreamCeiling limitations, and empty-result self-documentation. An agent has everything needed to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already documents most parameter behavior (e.g., offset's nextOffset, filter vendor limitations). The description adds the upstreamCeiling concept and synthesizes pagination flow in a clearer way, but much of this is already in the schema. It adds moderate value beyond the schema, so a 4 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 opens with a specific verb+resource: 'Fetch incident history and scheduled maintenance windows for a vendor.' It clearly distinguishes from siblings by focusing on incident data and explicitly names the filters and pagination. There is no ambiguity about what the tool returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context for each filter: 'use before deploy' for active incidents, 'for postmortem' for resolved, and mentions scheduled maintenance. It also refers to devops_list_vendors for finding vendor slugs. However, it does not explicitly compare to other sibling tools (e.g., when to use devops_status_check instead), though the purpose is distinct enough.
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 | Free-text search against vendor name and slug. Case-insensitive. 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. |
| 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 and idempotentHint=true, covering the safety profile. The description adds useful behavioral context by specifying the return fields and that it lists registry entries, with optional filters. It doesn't describe edge cases like empty results or pagination, but for a simple list tool with read-only annotations, the added context is sufficient.
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 concise sentences: the first states the action and filters, the second explains the output and the use case. Front-loaded with the core purpose and free of filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the presence of an output schema (which covers return format), and comprehensive annotations, the description is complete. It explains what the tool does, why to use it, and what information it returns. No critical information is missing for an agent to invoke 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?
The input schema provides 100% coverage: both parameters (query and category) have detailed descriptions with examples and the enum list is fully spelled out. The description adds no additional parameter semantics beyond what the schema already documents, so a 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 states a specific verb ('List') and resource ('vendors in the built-in registry') and immediately clarifies the optional filters and the output fields (slug, display name, category, status page URL). It is readily distinguishable from sibling tools, which all target other domains (certs, DNS, incidents, status, stacks).
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 use the tool: 'Use to discover the correct slug to pass to other tools, or to see which vendors are available before configuring a stack.' This provides clear context and a concrete purpose, effectively guiding the agent on appropriate invocation without ambiguity.
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, Firehydrant) and normalized to one shape. Returns per-vendor operational indicator (none = all clear, minor, major, critical, maintenance = scheduled window), degraded components, and active incidents. Use mode: "detailed" for component lists and maintenance windows, narrowed with component_filter and bounded by component_limit. Batch-friendly — pass a list to check your full stack in one call; a vendor that cannot be resolved or reached is reported in its own result row, so one bad entry never discards the rest.
| 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. | |
| component_limit | No | 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. | |
| component_filter | No | 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. |
| 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 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. |
| results | No | Per-vendor status results in the same order as the input vendors list. |
| summary | No | Aggregate health counts across all checked vendors. Buckets partition the batch: operational + degraded + down + maintenance + unavailable = total. |
| truncated | No | True when at least one vendor's component list was capped at component_limit. Absent when nothing was capped. |
| totalCount | No | Components matching component_filter across all vendors before the cap. Present only when truncated. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description is not responsible for the safety profile. The description adds meaningful behavioral context: normalization across different vendor APIs, per-vendor result rows with per-vendor operational indicators, and that one unreachable vendor never discards the rest. It also explains mode-dependent behavior and component filtering. This goes well beyond the annotations, though it omits details like caching or rate limits, which are minor given the read-only, idempotent nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long (several sentences) but each sentence contributes useful information: purpose, input formats, normalization, output shape, mode specifics, filtering, and error handling. It is front-loaded with the core purpose and scope, then flows to operational details. It could be tightened slightly, but the length is justified given the tool's complexity and the value added per sentence.
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 covers all essential aspects for correct use: input types (slugs/URLs), supported backends, normalizing behavior, output elements (indicator, degraded components, incidents), mode differences, filter and limit behavior, batch resilience, and discovery via devops_list_vendors. The output schema is provided, so the return structure is fully documented elsewhere. For a tool with four parameters and multiple modes, this description is complete and self-sufficient.
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 each parameter is already documented. The description adds value by explaining the interplay between mode, component_filter, and component_limit (e.g., filter applied before limit), and by giving examples of vendor slugs. It also clarifies that raw Statuspage URLs are supported only for Atlassian backends and that other backends require registry slugs. This enriches the schema without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Check') and resource ('current health status for one or more vendors'), and clarifies the scope with vendor slugs or Statuspage URLs. It distinguishes from siblings like devops_get_incidents by focusing on overall health, and references devops_list_vendors for slug discovery. The purpose is unambiguous and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it explains the two modes, how filtering/limits work, and notes the batch-friendly nature with error resilience. It references devops_list_vendors as an alternative for discovering slugs. However, it does not explicitly contrast with sibling tools like devops_get_incidents or devops_watch_stack, so an agent might miss why this is the right choice for a quick status check versus a deeper incident watch. That nuance is implied but not stated.
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 or display name (e.g., "cloudflare", "github"). Used to tailor category-specific guidance (CDN outage vs. CI/CD outage vs. auth provider outage). | |
| 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). 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 declare readOnlyHint=true and idempotentHint=true, so safety and side-effect characteristics are covered. The description adds behavioral detail about the output: it returns a playbook with pre-filled follow-up tool calls, and synthesizes from built-in knowledge and context. This goes beyond the annotations by explaining what the tool produces. No contradiction with annotations was found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences. The first sentence states the core purpose and output, the second adds context and usage guidance. No filler or redundancy. The most important information (playbook, vendor degradation, follow-up calls) is front-loaded. It is efficient and well-structured.
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?
This is a read-only, idempotent tool with an output schema (not shown), so return values are presumably documented there. The description covers the primary trigger (after status check or incidents), the input context (vendor, domain, summary, indicator, components), and the nature of the output. For a 5-parameter tool with clear annotations and schema, the description is complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters are thoroughly documented in the schema (e.g., vendor, your_domain, incident_summary, vendor_indicator, affected_components). The description does not repeat or augment these parameter meanings; it focuses on the overall behavior. Per the rubric, baseline 3 is appropriate when the schema carries the burden, which it does here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('return a playbook') with a clear resource (incident-response playbook) and context (tailored to vendor degradation). It also mentions the synthesis of category-specific guidance, which distinguishes it from other tools that only surface status or incidents. The purpose is unambiguous and immediately recognizable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use after devops_status_check or devops_get_incidents surfaces a problem to determine what to investigate next.' This gives a direct trigger condition and the exact preceding tools. It implies the tool is for follow-up, not initial discovery, and provides enough context for an agent to decide when to invoke it. No alternative tool is named, but the guidance is precise and sufficient.
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 persisted list. 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. 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. When omitted, uses the previously saved list for stack_name. | |
| 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 (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. | |
| component_filter | No | 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. |
| 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: 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. |
| notice | No | 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. |
| summary | No | Aggregate health counts across all checked vendors. Buckets partition the stack: operational + degraded + down + maintenance + unavailable = total. |
| vendors | No | Per-vendor status results. |
| truncated | No | True when at least one vendor's component list was capped at component_limit. 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 to state on this call. Only the vendors that resolved are saved — see omitted_vendors. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral traits beyond the annotations: it persists the vendor list on first call, and handles unresolvable vendors by excluding them from the saved stack. This is important side-effect information not present in the annotations (readOnlyHint=false, idempotentHint=true). The description adds meaningful context about state mutation and error handling, though annotations already indicate non-read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet complete, with each sentence serving a distinct purpose: defining the tool, explaining persistence, describing output, addressing edge cases, suggesting use cases, and clarifying multi-stack support. Information is front-loaded with the primary purpose, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of a detailed output schema (indicated by has_output_schema=true), the description only needs to cover selection and invocation context. It addresses the tool's purpose, usage timing, persistence side effects, error handling, and stack naming. No critical information is missing for an agent to correctly choose and invoke this tool.
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 each parameter has a detailed description. The tool description does not add additional meaning beyond what the schema provides; it only references the vendors and stack_name conceptually. The baseline of 3 is appropriate because the schema already documents all parameters thoroughly, and the description adds no extra semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check the health' and the resource 'named vendor stack', defining a specific purpose. It distinguishes itself from sibling tools (e.g., devops_check_certs, devops_check_dns) by focusing on a persisted list of vendors and an aggregate rollup. The resource is well-defined and the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: 'Ideal for morning status checks or pre-deploy sweeps' and explains the first-call vs subsequent-call pattern. It does not explicitly name alternative tools or state when NOT to use this tool, but the context is clear enough for an agent to infer appropriate use. The persistence behavior and multi-stack support further guide usage.
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. Dates show when Glama detected each change.
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."devops_get_incidents5 fields changedOutput schema / properties / cap / descriptionPrevious value: -"The limit that was applied."New value: +"The limit that was applied. Present only when truncated."Output schema / properties / incidents / items / properties / duration_minutes / descriptionPrevious value: -"Minutes from started_at to resolved_at. Null for active or scheduled incidents."New value: +"Minutes from started_at to resolved_at. Null for active or scheduled incidents, or when the vendor-authored timestamps are missing, invalid, or inverted."Output schema / properties / shown / descriptionPrevious value: -"Number of incidents returned after applying the limit."New value: +"Number of incidents returned after applying the limit. Present only when truncated."Output schema / properties / truncated / descriptionPrevious value: -"True when more incidents matched than the limit returned."New value: +"True when more incidents matched than the limit returned. Absent when the result was not capped."Output schema / requiredPrevious value: -[
- "vendor",
- "name",
- "incidents",
- "total_returned",
- "statuspage_url",
- "truncated",
- "shown",
- "cap"
-]New value: +[
+ "vendor",
+ "name",
+ "incidents",
+ "total_returned",
+ "statuspage_url"
+]devops_suggest_action4 fields changedInput schema / properties / vendor_indicatorAdded value: +{
+ "description": "Overall vendor status indicator from a prior devops_status_check call (its indicator field). When provided, the playbook leads with severity-tailored urgency guidance. Omit if status has not been checked yet.",
+ "enum": [
+ "none",
+ "minor",
+ "major",
+ "critical"
+ ],
+ "type": "string"
+}Output schema / properties / diagnostics_summary / properties / vendor_indicator / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "enum": [
+ "none",
+ "minor",
+ "major",
+ "critical"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / diagnostics_summary / properties / vendor_indicator / descriptionPrevious value: -"Overall vendor indicator from the calling context, or null when not provided as input."New value: +"Vendor status indicator echoed from the vendor_indicator input, or null when not provided."Output schema / properties / guidance / descriptionPrevious value: -"Markdown playbook — immediate steps, diagnostic checks, mitigation options, and what to monitor for resolution. Tailored to the vendor category and affected components."New value: +"Markdown playbook — immediate steps, diagnostic checks, mitigation options, and what to monitor for resolution. Tailored to the vendor category, reported severity, and affected components."devops_get_incidents4 fields changedOutput schema / properties / capAdded value: +{
+ "description": "The limit that was applied.",
+ "type": "number"
+}Output schema / properties / shownAdded value: +{
+ "description": "Number of incidents returned after applying the limit.",
+ "type": "number"
+}Output schema / properties / truncatedAdded value: +{
+ "description": "True when more incidents matched than the limit returned.",
+ "type": "boolean"
+}Output schema / requiredPrevious value: -[
- "vendor",
- "name",
- "incidents",
- "total_returned",
- "statuspage_url"
-]New value: +[
+ "vendor",
+ "name",
+ "incidents",
+ "total_returned",
+ "statuspage_url",
+ "truncated",
+ "shown",
+ "cap"
+]devops_check_certsdevops_check_dnsdevops_get_incidentsdevops_list_vendorsdevops_status_checkdevops_suggest_actiondevops_watch_stackstatus_checkstatus_check_certsstatus_check_dnsstatus_get_incidentsstatus_list_vendorsstatus_suggest_actionstatus_watch_stackClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Monitoring for agencies — uptime, SSL, DNS, blocklists, AI visibility, MCP health. 8 no-auth tools.
Live DNS, email-auth and redirect checks, HTTP security headers, uptime history, PC hardware prices.
Uptime, API and server monitoring with outages, reporting, on-call and status pages.
DNS lookups, health reports, SSL certs, security scans, GEO scoring, uptime checks
Add one secure layer between your agents and this server.
Each tool targets a distinct aspect of DevOps status monitoring: certificate health, DNS resolution, incident history, vendor discovery, current status, action suggestions, and stack monitoring. Even the overlapping status_check and watch_stack have clear differences (arbitrary targets vs saved stacks). No ambiguity.
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 inverts to noun_verb, but it's still readable and doesn't cause confusion.
7 tools is well within the 3-15 sweet spot for a domain-specific server. Each tool covers a necessary function with no redundancy or bloat, making the surface area easy to navigate.
The tool set covers the core lifecycle of DevOps status monitoring: discovery, health checks, incident lookup, certificate and DNS checks, and actionable recommendations. Minor gaps like a dedicated tool for viewing a single incident in isolation are mitigated by filtering in get_incidents. The stack management is a bonus that adds convenience.
