Skip to main content
Glama

Devops Get Incidents

devops_get_incidents
Read-onlyIdempotent

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 not reachable at a higher offset. On Atlassian Statuspage vendors, since (a date up to 24 months back) also reads the status page's quarterly history archive back to that date where the page publishes one; those records are marked source: "history" and carry the title, impact, start and end times, and final update message only. An empty result, or a history read that stopped short of since, explains itself in notice.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum incidents to return per call (1–50). Page through longer history with offset rather than raising this.
sinceNoEarliest start date to include, as YYYY-MM-DD (UTC), at most 24 months back. Accepted with filter "all" or "resolved". Incidents that started before it are left out, and limit/offset page the rest. On Atlassian Statuspage vendors it also reads the status page's quarterly history archive back to this date, reaching incidents older than the 50 the status API serves. Omit to read only the status API.
filterNoall: incidents plus scheduled maintenances. active: only incidents with status investigating/identified/monitoring. resolved: only fully resolved incidents. scheduled: only scheduled maintenance windows. Not every vendor backend serves every filter — "aws" lists a resolved event only until it drops off its feed, "azure" lists open items only (never resolved), and "aws", "azure", "gcp", and "slack" publish no maintenance windows. An empty result names which case applied.all
offsetNoNumber 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.
vendorYesVendor slug (e.g., "github", "aws") or raw Atlassian Statuspage base URL. Use devops_list_vendors to find slugs.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
capNoThe limit that was applied. Present only when truncated.
nameNoDisplay name of the vendor.
errorNoPresent when the call failed. Absent on success.
shownNoNumber of incidents returned after applying the limit. Present only when truncated.
noticeNoPlain-language explanation of this result — how to page onward, why it came back empty (the vendor currently publishes nothing at all, a filter the backend cannot satisfy, an offset past the end, or a since date that left everything out), that the vendor feed capped the history, or how far the history archive was read when it stopped short of since. Absent when the result needs no explanation.
vendorNoVendor slug or URL as provided.
incidentsNoMatching incidents.
truncatedNoTrue when more incidents matched than the limit returned. Absent when the result was not capped.
nextOffsetNoThe 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.
totalCountNoTotal incidents matching the filter, across all pages, before offset/limit windowing. Present only when the result was truncated.
statuspage_urlNoStatus page base URL used.
total_returnedNoNumber of incidents in the response.
upstreamCeilingNoMaximum incidents the vendor's own status API serves in one fetch, present only when that ceiling was reached on this call. It bounds the history independently of limit and offset: incidents older than the oldest one returned cannot be fetched at any offset. On Atlassian Statuspage vendors, since reads past it from the page's history archive. Absent when the vendor feed is unbounded, returned less than its ceiling, or since was set and the history archive was read back to it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed16 schema fields changed
    • changedInput schema / properties / filter / description
      Previous value: -"all: incidents plus scheduled maintenances. active: only incidents with status investigating/identified/monitoring. resolved: only fully resolved incidents. scheduled: only scheduled maintenance windows. Not every vendor backend serves every filter — \"aws\" publishes currently-open events only (never resolved, no maintenance windows), and \"gcp\" and \"slack\" publish no maintenance windows. An empty result names which case applied."New value: +"all: incidents plus scheduled maintenances. active: only incidents with status investigating/identified/monitoring. resolved: only fully resolved incidents. scheduled: only scheduled maintenance windows. Not every vendor backend serves every filter — \"aws\" lists a resolved event only until it drops off its feed, \"azure\" lists open items only (never resolved), and \"aws\", \"azure\", \"gcp\", and \"slack\" publish no maintenance windows. An empty result names which case applied."
    • addedInput schema / properties / since
      Added value: +{
      +  "anyOf": [
      +    {
      +      "const": "",
      +      "type": "string"
      +    },
      +    {
      +      "description": "Earliest start date to include, as YYYY-MM-DD (UTC), e.g. \"2025-10-01\".",
      +      "format": "date",
      +      "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
      +      "type": "string"
      +    }
      +  ],
      +  "description": "Earliest start date to include, as YYYY-MM-DD (UTC), at most 24 months back. Accepted with filter \"all\" or \"resolved\". Incidents that started before it are left out, and limit/offset page the rest. On Atlassian Statuspage vendors it also reads the status page's quarterly history archive back to this date, reaching incidents older than the 50 the status API serves. Omit to read only the status API."
      +}
    • changedOutput schema / properties / error / properties / data / properties / reason / description
      Previous value: -"Machine-readable failure mode. Declared by this tool: `vendor_not_found`: Vendor slug not in registry and input is not a valid URL. `target_blocked`: A raw URL resolves to a private, loopback, or cloud-metadata address. `statuspage_unavailable`: The vendor's status API returned an error or timed out. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `vendor_not_found`: Vendor slug not in registry and input is not a valid URL. `target_blocked`: A raw URL resolves to a private, loopback, or cloud-metadata address. `invalid_since`: since was passed with filter \"active\" or \"scheduled\", or is more than 24 months back. `statuspage_unavailable`: The vendor's status API returned an error or timed out. Other values are possible when a failure originates below the handler."
    • changedOutput schema / properties / error / properties / data / properties / reason / examples
      Previous value: -[
      -  "vendor_not_found",
      -  "target_blocked",
      -  "statuspage_unavailable"
      -]New value: +[
      +  "vendor_not_found",
      +  "target_blocked",
      +  "invalid_since",
      +  "statuspage_unavailable"
      +]
    • changedOutput schema / properties / incidents / items / properties / created_at / description
      Previous value: -"ISO 8601 UTC timestamp when the incident was created."New value: +"ISO 8601 timestamp when the incident was created, carrying the UTC offset the vendor published (Z, +00:00, or a local offset such as -07:00). For a history-archive record, the start time its status page displays, to the minute, in UTC."
    • changedOutput schema / properties / incidents / items / properties / resolved_at / description
      Previous value: -"ISO 8601 UTC timestamp when resolved, or null if still active."New value: +"ISO 8601 timestamp, with the vendor's UTC offset, when resolved, or null if still active. For a history-archive record, to the minute, in UTC."
    • changedOutput schema / properties / incidents / items / properties / scheduled_for / description
      Previous value: -"Present for scheduled maintenances — ISO 8601 UTC start time."New value: +"Present for scheduled maintenances — ISO 8601 start time with the vendor's UTC offset."
    • changedOutput schema / properties / incidents / items / properties / scheduled_until / description
      Previous value: -"Present for scheduled maintenances — ISO 8601 UTC end time."New value: +"Present for scheduled maintenances — ISO 8601 end time with the vendor's UTC offset."
    • addedOutput schema / properties / incidents / items / properties / source
      Added value: +{
      +  "description": "Where this record came from. api: the vendor's status API, with the full update timeline and affected components. history: the status page's quarterly history archive, read only when since is set — title, impact, start and end times, and the final update message, with no components and no started_at, scheduled window, or duration.",
      +  "enum": [
      +    "api",
      +    "history"
      +  ],
      +  "type": "string"
      +}
    • changedOutput schema / properties / incidents / items / properties / started_at / description
      Previous value: -"ISO 8601 UTC timestamp when the incident started, or null/absent if not set by the vendor."New value: +"ISO 8601 timestamp, with the vendor's UTC offset, when the incident started, or null/absent if not set by the vendor."
    • changedOutput schema / properties / incidents / items / properties / status / description
      Previous value: -"Current status: investigating | identified | monitoring | resolved | postmortem | scheduled | in_progress | completed."New value: +"Current status: investigating | identified | monitoring | resolved | postmortem | scheduled | in_progress | completed | unknown. unknown marks a history-archive record with no end time, whose lifecycle stage the archive does not publish."
    • changedOutput schema / properties / incidents / items / properties / updates / description
      Previous value: -"Chronological list of incident updates (oldest first)."New value: +"Chronological list of incident updates (oldest first). A history-archive record carries only its final update, dated at its end time (or its start when it has none)."
    • changedOutput schema / properties / incidents / items / properties / updates / items / properties / created_at / description
      Previous value: -"ISO 8601 UTC timestamp of this update."New value: +"ISO 8601 timestamp of this update, with the vendor's UTC offset."
    • changedOutput schema / properties / incidents / items / required
      Previous value: -[
      -  "id",
      -  "name",
      -  "impact",
      -  "status",
      -  "created_at",
      -  "resolved_at",
      -  "scheduled_for",
      -  "scheduled_until",
      -  "duration_minutes",
      -  "affected_components",
      -  "updates"
      -]New value: +[
      +  "id",
      +  "name",
      +  "impact",
      +  "status",
      +  "created_at",
      +  "resolved_at",
      +  "scheduled_for",
      +  "scheduled_until",
      +  "duration_minutes",
      +  "affected_components",
      +  "updates",
      +  "source"
      +]
    • changedOutput schema / properties / notice / description
      Previous value: -"Plain-language explanation of this result — how to page onward, why it came back empty (the vendor currently publishes nothing at all, a filter the backend cannot satisfy, or an offset past the end), or that the vendor feed capped the history. Absent when the result needs no explanation."New value: +"Plain-language explanation of this result — how to page onward, why it came back empty (the vendor currently publishes nothing at all, a filter the backend cannot satisfy, an offset past the end, or a since date that left everything out), that the vendor feed capped the history, or how far the history archive was read when it stopped short of since. Absent when the result needs no explanation."
    • changedOutput schema / properties / upstreamCeiling / description
      Previous value: -"Maximum incidents the vendor's own status API serves in one fetch, present only when that ceiling was reached on this call. It bounds the history independently of limit and offset: incidents older than the oldest one returned cannot be fetched at any offset, only browsed on the vendor status page. Absent when the vendor feed is unbounded or returned less than its ceiling."New value: +"Maximum incidents the vendor's own status API serves in one fetch, present only when that ceiling was reached on this call. It bounds the history independently of limit and offset: incidents older than the oldest one returned cannot be fetched at any offset. On Atlassian Statuspage vendors, since reads past it from the page's history archive. Absent when the vendor feed is unbounded, returned less than its ceiling, or since was set and the history archive was read back to it."
  2. Changed12 schema fields changed
    • removedOutput schema / properties / incidents / items / properties / duration_minutes / anyOf
      Removed value: -[
      -  {
      -    "type": "number"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / incidents / items / properties / duration_minutes / type
      Added value: +[
      +  "number",
      +  "null"
      +]
    • removedOutput schema / properties / incidents / items / properties / resolved_at / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / incidents / items / properties / resolved_at / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / incidents / items / properties / scheduled_for / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / incidents / items / properties / scheduled_for / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / incidents / items / properties / scheduled_until / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / incidents / items / properties / scheduled_until / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / incidents / items / properties / shortlink / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / incidents / items / properties / shortlink / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / incidents / items / properties / started_at / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / incidents / items / properties / started_at / type
      Added value: +[
      +  "string",
      +  "null"
      +]
  3. Changed6 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedInput schema / additionalProperties
      Added value: +false
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedOutput schema / anyOf
      Added value: +[
      +  {
      +    "not": {
      +      "required": [
      +        "error"
      +      ]
      +    },
      +    "required": [
      +      "vendor",
      +      "name",
      +      "incidents",
      +      "total_returned",
      +      "statuspage_url"
      +    ]
      +  },
      +  {
      +    "required": [
      +      "error"
      +    ]
      +  }
      +]
    • addedOutput schema / properties / error
      Added 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"
      +}
    • removedOutput schema / required
      Removed value: -[
      -  "vendor",
      -  "name",
      -  "incidents",
      -  "total_returned",
      -  "statuspage_url"
      -]
  4. Changed1 schema field changed
    • changedOutput schema / properties / notice / description
      Previous 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."
  5. Changed1 schema field changed
    • changedInput schema / properties / filter / description
      Previous 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."
  6. Changed5 schema fields changed
    • changedInput schema / properties / filter / description
      Previous 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."
    • changedInput schema / properties / offset / description
      Previous 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."
    • addedOutput schema / properties / nextOffset
      Added 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"
      +}
    • addedOutput schema / properties / notice
      Added 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"
      +}
    • addedOutput schema / properties / upstreamCeiling
      Added 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"
      +}
  7. Changed3 schema fields changed
    • changedInput schema / properties / limit / description
      Previous 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."
    • addedInput schema / properties / offset
      Added 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"
      +}
    • addedOutput schema / properties / totalCount
      Added value: +{
      +  "description": "Total incidents matching the filter, across all pages, before offset/limit windowing. Present only when the result was truncated.",
      +  "type": "number"
      +}
  8. Changed4 schema fields changed
    • changedInput schema / properties / limit / description
      Previous 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."
    • changedInput schema / properties / vendor / description
      Previous 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."
    • changedOutput schema / properties / incidents / items / properties / id / description
      Previous value: -"Unique incident identifier from Statuspage."New value: +"Unique incident identifier from the vendor's status API."
    • changedOutput schema / properties / statuspage_url / description
      Previous value: -"Statuspage base URL used."New value: +"Status page base URL used."
  9. Changed5 schema fields changed
    • changedOutput schema / properties / cap / description
      Previous value: -"The limit that was applied."New value: +"The limit that was applied. Present only when truncated."
    • changedOutput schema / properties / incidents / items / properties / duration_minutes / description
      Previous 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."
    • changedOutput schema / properties / shown / description
      Previous value: -"Number of incidents returned after applying the limit."New value: +"Number of incidents returned after applying the limit. Present only when truncated."
    • changedOutput schema / properties / truncated / description
      Previous 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."
    • changedOutput schema / required
      Previous value: -[
      -  "vendor",
      -  "name",
      -  "incidents",
      -  "total_returned",
      -  "statuspage_url",
      -  "truncated",
      -  "shown",
      -  "cap"
      -]New value: +[
      +  "vendor",
      +  "name",
      +  "incidents",
      +  "total_returned",
      +  "statuspage_url"
      +]
  10. Changed4 schema fields changed
    • addedOutput schema / properties / cap
      Added value: +{
      +  "description": "The limit that was applied.",
      +  "type": "number"
      +}
    • addedOutput schema / properties / shown
      Added value: +{
      +  "description": "Number of incidents returned after applying the limit.",
      +  "type": "number"
      +}
    • addedOutput schema / properties / truncated
      Added value: +{
      +  "description": "True when more incidents matched than the limit returned.",
      +  "type": "boolean"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "vendor",
      -  "name",
      -  "incidents",
      -  "total_returned",
      -  "statuspage_url"
      -]New value: +[
      +  "vendor",
      +  "name",
      +  "incidents",
      +  "total_returned",
      +  "statuspage_url",
      +  "truncated",
      +  "shown",
      +  "cap"
      +]
  11. Added

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description richly discloses behavior beyond the readOnly/openWorld/idempotent annotations: pagination through nextOffset, upstreamCeiling indicating vendor-side history caps, Statuspage quarterly archive behavior with source: 'history' records, and notice fields explaining empty or shortened results. This gives the agent accurate expectations about edge cases.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every sentence carries distinct operational value: scope, filter use cases, paging mechanics, vendor ceilings, Statuspage archive behavior, and empty-result notices. It is front-loaded with the core purpose and then layers complexity, with no redundant restatement of the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex, vendor-variant tool with five parameters and an output schema, the description covers the critical context: when to use each filter, how paging works, what vendor caps mean, and how to interpret truncated results. The existing schema covers parameter syntax, and the output schema covers return structure, so nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: it ties filter values to deployment/postmortem workflows, explains how offset/limit and nextOffset interact in truncation, and clarifies vendor-specific filter limitations such as 'aws' only listing resolved events until they drop off. This materially helps the agent pick values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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: 'Fetch incident history and scheduled maintenance windows for a vendor.' It also clarifies what the returned timeline contains (investigator updates, affected components, resolution), making the tool's scope unmistakable and distinct from sibling status-check tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit use context: 'use before deploy' for active incidents, 'for postmortem' for resolved history, and upcoming maintenance windows. It does not explicitly name when to prefer a sibling like devops_status_check, but the clear task-oriented guidance is strong enough to select the right tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.