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.6/5 across 7 of 7 tools scored.
Each tool has a clearly distinct purpose: cert check, DNS check, incident history, vendor list, current status, action suggestion, and stack health. Even the overlapping status_check and watch_stack are differentiated by generic vs. saved-stack usage.
All tools share the 'devops_' prefix and mostly use verb_noun (check_certs, check_dns, get_incidents, list_vendors, suggest_action, watch_stack). 'devops_status_check' breaks the verb-first pattern, but it's a minor deviation.
Seven tools is well-scoped for a devops status server. Each tool covers a distinct aspect of checking and responding to infrastructure health, without unnecessary bloat.
Core lifecycle is covered: list vendors, check status, check DNS/certs for deeper diagnostics, fetch incident history, suggest actions, and monitor stacks. Minor gap: no read-only tool to list saved stack definitions, but watch_stack serves that purpose indirectly.
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 the readOnlyHint, openWorldHint, and idempotentHint annotations, the description adds meaningful behavioral context: it reports typed outcomes distinguishing nxdomain, servfail, and nodata, explains that resolver disagreements are reported without asserting cause, and describes partial_resolution and value_variation. The 'no vendor registry required' note also clarifies operational 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 front-loaded with the main action, then adds essential behavioral detail and a practical pairing note. Every sentence contributes value, with no redundancy or filler. It is structured logically from purpose to outcomes to alternatives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description still enriches understanding by explaining the meaning of resolver outcomes and distinguishing edge cases. It covers purpose, behavior, and integration with a sibling tool, making it complete for a tool with 4 params and rich output semantics.
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 with descriptions for all four parameters. The description mentions record types and resolvers generically but does not add new parameter-specific meaning beyond what the schema already documents. Baseline of 3 is appropriate given full schema coverage.
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 public resolvers and compares results, using the specific verb 'Resolve' with a defined resource. It distinguishes itself from siblings by mentioning pairing with devops_check_certs for TLS issues, and notes it works for any domain with no vendor registry required.
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 an alternative: 'Pair with devops_check_certs when a domain resolves but TLS to it is failing.' It also implies appropriate use cases by explaining how to interpret resolver disagreements and when partial_resolution or value_variation indicate propagation or steady-state conditions.
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 (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 | 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?
Beyond the readOnly/openWorld/idempotent annotations, the description discloses pagination behavior (nextOffset), vendor caps (upstreamCeiling), and self-explanatory empty results. It also notes that truncated results disclose totals, adding 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?
Every sentence earns its place, starting with the core purpose and then logically covering filters, pagination, vendor limitations, and empty results. No fluff or redundancy; the length is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is thorough for a tool with a rich output schema: it covers usage scenarios, pagination edge cases, vendor caps, and empty-result behavior. The existing output schema handles return values, so the description focuses on behavioral and contextual details, leaving no significant gaps.
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 already covers 100% of parameters with detailed descriptions, setting a baseline of 3. The description adds value by linking filter values to practical use cases (before deploy, postmortem) and explaining how limit and offset interact via nextOffset, going slightly beyond the raw 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 opens with 'Fetch incident history and scheduled maintenance windows for a vendor,' providing a specific verb and resource. It clearly distinguishes from siblings like devops_status_check by focusing on historical data and scheduled maintenance, and elaborates on the returned timeline components.
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 concrete when-to-use guidance: 'use before deploy' for active incidents, 'for postmortem' for resolved history, and upcoming maintenance windows. It does not explicitly name alternatives or exclusionary scenarios, but the practical 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_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, 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. |
| 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 + 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 convey read-only and idempotent behavior. The description adds significant behavioral detail: normalization across vendor APIs, per-vendor indicator meanings, failure isolation ('one bad entry never discards the rest'), and the distinction between summary/detailed modes. This goes well beyond the annotation hints.
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 information-dense yet concise, with each sentence serving a purpose: purpose statement, accepted formats, normalization, return shape, mode usage, and batch behavior. No fluff or repetition; front-loaded with the core action.
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 moderate complexity (4 params, output schema present), the description is complete: it covers inputs, output shape, mode variations, error handling, and batch use. The output schema handles return structure, and the description fills in behavioral and usage nuances, leaving no significant gaps.
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 enriches parameter understanding: it explains vendor slugs vs raw URLs, the summary/detailed mode semantics, how component_filter interacts with component_limit, and that component_filter is case-insensitive. This adds practical meaning beyond the schema's field descriptions.
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 current health status for vendors, distinguishing it from siblings like certs or DNS checks. It specifies accepted inputs (slugs or Statuspage URLs), normalized output shape, and return values, leaving no ambiguity about the tool's core function.
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 clear usage context: batch-friendly for full-stack checks, mode selection for detail level, and component_filter/component_limit for narrowing results. However, it does not explicitly compare to sibling tools (e.g., devops_get_incidents) or state when not to use this tool, so it falls short of full alternative guidance.
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 mark the tool as read-only and idempotent, and the description adds that it synthesizes from built-in knowledge and pre-fills follow-up tool calls, clarifying that it doesn't execute changes. This is useful behavioral context beyond the hints and no contradiction exists.
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, first leading with the core purpose, second adding synthesis logic and usage context. Every word earns its place with no 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?
The description covers what, when, and how the tool works, and with a rich output schema and full parameter schema coverage, it is nearly complete. A minor gap is not addressing unknown vendors or edge cases, but these are not essential given the schema detail.
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?
Input schema covers 100% of the parameters with detailed descriptions, so the baseline is 3. The description mentions using 'provided context' but adds no specific parameter guidance beyond what the schema already offers.
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 uses a specific verb ('Return') and defines a distinct deliverable ('incident-response playbook tailored to a vendor degradation, with pre-filled follow-up tool calls'). It clearly differentiates from sibling tools by stating it synthesizes category-specific guidance and positions it as a next-step after status/incident checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use after devops_status_check or devops_get_incidents surfaces a problem', providing clear workflow context. While it names when to use it, it doesn't explicitly list exclusions or alternative tools for different scenarios, but the sequencing is clear.
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, 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 | Yes | Aggregate health counts across all checked vendors. Buckets partition the stack: operational + degraded + down + maintenance + 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?
The description discloses significant behavioral traits beyond the annotations, including statefulness (persisting the vendor list), failure handling (failed vendors are excluded from the saved stack), and output structure (aggregate rollup plus per-vendor detail). This adds valuable context that the annotations do not provide, and there is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with four sentences each adding value: purpose, persistence behavior, output/failure handling, and use cases. No redundancy or filler, and it is front-loaded with the primary function.
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 (persistent state, aggregation, failure handling) and the presence of a full output schema, the description is complete. It covers what the tool does, how state is managed, the response format, failure behavior, and suggested use cases, providing a comprehensive mental model for the agent.
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 schema already covers all parameters with detailed descriptions, giving a baseline of 3. The description adds complementary insights, such as the 'vendors' parameter being required on first call and optional afterwards, and the 'stack_name' parameter allowing multiple stacks. This enhances the agent's understanding of parameter usage 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's purpose: 'Check the health of a named vendor stack — a saved list of vendors representing your infrastructure dependencies.' It uses a specific verb ('check') and resource ('vendor stack'), and distinguishes itself from sibling tools by emphasizing aggregate rollup and persistence. This makes it obvious when to choose this tool over alternatives like devops_status_check.
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 context: 'Ideal for morning status checks or pre-deploy sweeps' and explains the first-call vs. subsequent-call behavior for defining/reusing the stack. It does not explicitly name alternatives or state when not to use it, but the guidance is sufficient for most use cases.
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.
