Skip to main content
Glama
Sign In
iran-cloud-status-mcp

iran-cloud-status-mcp

by sepehr071
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

One incident in detail

cs_incident
Read-onlyIdempotent

Retrieve one incident's full update timeline, affected components, and per-component statuses by provider and incident ID; use after incident or status listings.

Instructions

Show one incident with its full update timeline, affected components and the status each was set to.

Use it after cs_incidents or cs_status. Hamravesh lookup covers only the latest ~800 history entries.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "provider": "<provider>",
      "incident_id": "<incident_id>"
    },
    "name": "cs_incident"
  }
}

Input Schema

NameRequiredDescriptionDefault
providerYesProvider id (not mihanwebhost).
incident_idYes`id` from cs_incidents or cs_status.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the response includes a full update timeline with per-component statuses, and the Hamravesh lookup is limited to roughly the latest 800 history entries, which warns the agent about truncated results.

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?

Two short sentences with no filler. The return-content summary is front-loaded and the usage/limitation note follows, so an agent gets the essential facts in the first line.

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

Completeness4/5

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

With no output schema, the description carries the burden of describing return values, and it does so by naming the timeline, components, and statuses. The Hamravesh history cap is a useful caveat; only minor gaps remain, such as whether other providers have similar truncation or how large timelines are returned.

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

Parameters3/5

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

Schema description coverage is 100%, so both parameters are already documented, including that incident_id comes from cs_incidents or cs_status. The description adds no new syntax, format, or constraint detail beyond the schema, so the baseline of 3 applies.

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?

States a specific verb and resource ('Show one incident') and enumerates the payload it returns: full update timeline, affected components, and per-component status. This clearly separates it from the sibling list tool cs_incidents, which returns many incidents rather than one detailed record.

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?

Explicitly routes the agent: 'Use it after cs_incidents or cs_status,' naming the two siblings that produce the incident_id this tool consumes. It does not spell out when to prefer cs_status over cs_incidents as the entry point, but the sequencing guidance is concrete rather than implied.

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

Deploy Server

Other Tools