Vendor status pages, TLS cert inspection, DNS propagation checks, and incident-response playbooks.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.5/5 across 7 of 7 tools scored.
Each tool has a clearly distinct purpose: certificate checks, DNS resolution, incident retrieval, vendor listing, status checking, action suggestions, and stack monitoring. No overlap in functionality.
All tools follow a consistent 'devops_verb_noun' pattern in snake_case (e.g., devops_check_certs, devops_list_vendors), making naming predictable and easy to navigate.
Seven tools is an ideal scope for a DevOps status monitoring server, covering core operations without being bloated or insufficient. Each tool earns its place.
The tool set covers the full lifecycle of DevOps status monitoring: DNS/SSL checks, vendor discovery, status checks, incident history, action recommendations, and stack monitoring. No obvious gaps.
devops_check_certsDevops Check CertsAInspect 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 |
|---|---|---|
| results | Yes | Per-domain certificate inspection results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses detailed behavior beyond annotations: performs real handshake, reports broken certs instead of hiding errors, explains specific error fields (hostname_verification_error, authorization_error) and their critical status. No contradiction with readOnlyHint, idempotentHint, openWorldHint.
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?
Packed with information in ~150 words without redundancy. Front-loaded with main purpose, each sentence adds value (e.g., handshake behavior, thresholds, error handling, sibling guidance). No 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 has an output schema (not shown but confirmed), description does not need to detail return values. It still explains key output fields and thresholds. Covers all necessary context for a network check tool with 3 parameters and rich behavior.
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% (baseline 3). Description adds meaningful context: for 'domains' warns about not including protocol and limits to 10; for 'port' gives example 8443; for 'timeout_ms' explains default from env var and when to increase. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inspects SSL/TLS certificate health via a real TLS handshake, listing specific reported fields (expiry, subject, SANs, issuer, etc.). It explicitly distinguishes from sibling devops_check_dns by noting when to use that instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: works for any internet-accessible domain, no vendor registry needed. Tells when to use (check cert health) and when not (if domain fails to connect, use devops_check_dns first). Includes alternatives clearly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
devops_check_dnsDevops Check DnsAResolve 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 |
|---|---|---|
| results | Yes | Per-domain DNS resolution results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint, idempotentHint), the description details behavioral traits: reports resolution latency, typed outcomes (nxdomain, servfail, nodata), and resolver disagreements (partial_resolution, value_variation) without asserting cause, adding significant context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but well-structured, front-loading the main purpose. It is moderately long but every sentence adds value, though it could be slightly more concise.
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 an output schema (not shown) and the complexity of DNS resolution with multiple resolvers and record types, the description fully explains return values and behaviors, completing the 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 coverage is 100%, so baseline is 3. The description adds meaning: explains domain count limit, resolver IP literal requirement with env var exception, timeout default from env var, and record type defaults with usage suggestions. This goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves DNS records across multiple resolvers and compares results, distinguishing it from siblings by focusing on resolver comparison and mentioning a pairing with devops_check_certs.
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 explains the tool works for any domain without vendor registry and provides guidance on record types, including when to add NS or CNAME. It also explicitly pairs with devops_check_certs for TLS issues, but lacks explicit when-not-to-use statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
devops_get_incidentsDevops Get IncidentsAFetch 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 | Yes | Display name of the vendor. |
| 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 (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 | Yes | Vendor slug or URL as provided. |
| incidents | Yes | 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 | Yes | Status page base URL used. |
| total_returned | Yes | 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 already declare readOnlyHint, openWorldHint, idempotentHint. Description adds value beyond these: explains paging (offset, nextOffset), upstreamCeiling limit for vendor history, empty result explanation, and vendor-specific behaviors. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single coherent paragraph of ~120 words, front-loaded with purpose. Every sentence adds value (paging, vendor quirks, filtering). Slightly dense but not verbose; could be split for readability but still concise.
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 has 4 parameters, 100% schema coverage, and an output schema (not shown but exists), the description covers all necessary behavioral details: paging, upstream limitations, vendor-specific behaviors, and empty result handling. It fully equips an agent to use the 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 has 100% coverage. Description adds meaningful context: explains filter options with use cases (active for deploy, resolved for postmortem), vendor-specific constraints (AWS, GCP, Slack), and paging mechanics (limit+offset, nextOffset). Enhances understanding beyond schema defaults.
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 it fetches incident history and scheduled maintenance windows for a vendor, with specific details on return data (timeline, updates, components, resolution). It distinguishes from sibling tools which focus on certificates, DNS, status checks, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use each filter (e.g., 'use before deploy' for active, 'postmortem' for resolved) and notes vendor limitations (e.g., AWS only active, GCP/Slack no maintenance). Does not explicitly name alternatives among siblings but context suffices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
devops_list_vendorsDevops List VendorsAList 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 |
|---|---|---|
| total | Yes | Total number of vendors returned. |
| vendors | Yes | Matching vendors from the built-in registry. |
| categories | Yes | 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 and idempotentHint true, so little behavioral burden falls on description. Description adds that results are optionally filtered, which is consistent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with clear front-loading: action, return fields, usage guidance. No wasted text.
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 annotations covering safety/idempotence, output schema implied, and schema covering parameters, the description provides sufficient context for a list/retrieval 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 coverage is 100% with detailed descriptions for both parameters. Description only mentions optional filters, adding no new meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists vendors in the built-in registry with optional filters, specifies returned fields (slug, display name, category, status page URL), and distinguishes itself by mentioning slug discovery for other tools.
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 instructs to use for discovering slugs or checking available vendors before stack configuration, providing clear context. No explicit when-not, but sibling tools suggest different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
devops_status_checkDevops Status CheckACheck 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), 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. |
| 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 | Yes | Per-vendor status results in the same order as the input vendors list. |
| summary | Yes | Aggregate health counts across all checked vendors. Buckets partition the batch: operational + degraded + down + 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 readonly/idempotent/openWorld. Description adds valuable behavioral context: normalization, per-vendor resilience (one bad entry doesn't discard rest), and unreachable vendor handling.
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?
Reasonably concise for the information density; well-structured with clear front-loading of purpose. Could trim some examples but still efficient.
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 output schema available, description covers return values adequately. Also addresses edge cases (unreachable vendors, component narrowing) and provides sufficient detail for safe 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 coverage is 100%. Description adds real meaning beyond schema: examples for vendors, usage tips for component_limit vs component_filter, and mode semantics.
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?
Description clearly states it checks health status for vendors, details output (indicator, degraded components, incidents), and distinguishes from siblings like devops_get_incidents and devops_list_vendors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on mode selection, component_filter usage, and batching; mentions devops_list_vendors for discovery. Lacks explicit 'when not to use' but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
devops_suggest_actionDevops Suggest ActionAReturn 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 |
|---|---|---|
| vendor | Yes | Vendor as provided. |
| guidance | Yes | 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 | Yes | Detected category from registry (e.g., "cdn-edge", "auth"). Null for unrecognized vendors. |
| diagnostics_summary | Yes | Summary of input context used to generate the playbook. |
| nextToolSuggestions | Yes | 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. Description adds behavioral context: it synthesizes from built-in knowledge and context, and pre-fills follow-up tool calls. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a usage note. Efficiently front-loads purpose and usage. Every sentence is informative and 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 has an output schema, the description does not need to explain return values. It covers purpose, usage, behavioral context, and is complete for a complex tool with 5 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add significant meaning beyond what the schema already provides for parameters.
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?
Description clearly states it returns an incident-response playbook with pre-filled tool calls, tailored to vendor degradation. It distinguishes from siblings by specifying the use case after devops_status_check or devops_get_incidents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use after devops_status_check or devops_get_incidents surfaces a problem. Provides clear context but does not explicitly name alternatives or exclude other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
devops_watch_stackDevops Watch StackACheck 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"). | 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. |
| shown | No | Components returned across the stack. Present only when truncated. |
| health | Yes | 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. |
| 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 | Yes | Aggregate health counts across all checked vendors. Buckets partition the stack: operational + degraded + down + unavailable = total. |
| vendors | Yes | 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 | Yes | ISO 8601 UTC timestamp of this check. |
| stack_name | Yes | Name of the stack checked. |
| totalCount | No | Components matching component_filter across the stack before the cap. Present only when truncated. |
| omitted_vendors | Yes | 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 | Yes | 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?
Describes key behaviors: first call defines stack, subsequent calls reuse; unresolved vendors are reported but not persisted; multiple stacks coexist. Annotations already indicate idempotent and non-destructive, so description adds significant behavioral context.
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?
Six well-structured sentences, front-loaded with main purpose, no redundancy. Every sentence adds value.
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?
Fully covers the tool's purpose, usage pattern, parameter behavior, error handling, and multiple stack support. Output schema exists, so return values are not needed in description.
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%, but the description adds value by explaining the lifecycle (first call vs. subsequent), the purpose of stack_name for multiple stacks, and the relationship between component_limit and component_filter. This exceeds the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks the health of a named vendor stack, a saved list of vendors. It distinguishes from sibling tools (certs, DNS, incidents, etc.) by focusing on a composite health snapshot of multiple vendors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It recommends use for 'morning status checks or pre-deploy sweeps' and explains the first-call setup vs. subsequent reuse. It does not explicitly contrast with sibling tools, but the unique purpose is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!
Sign in to create a connector for this server.
