# API Status Check

> Live status probes plus published uptime and incident history for 280+ APIs and cloud services.

- name: io.github.shibley/apistatuscheck
- version: 0.2.3
- connection class: R0 (autonomous)
- trust: 94/100
- quality: 79/100 (good)
- owner: not claimed
- descriptor: https://api.protogrid.dev/v1/servers/io.github.shibley%2Fapistatuscheck
- tools: https://api.protogrid.dev/v1/servers/io.github.shibley%2Fapistatuscheck/tools

**An agent can connect right now, no human step.** Remote endpoint, no authentication, reachable on the last probe.

## Connection (mcpServers)

```json
{
  "mcpServers": {
    "apistatuscheck": {
      "type": "http",
      "url": "https://apistatuscheck.com/api/mcp"
    }
  }
}
```


## Trust

- hygiene: 100
- liveness: 100
- freshness: 85
- provenance: 90
- drivers: +repository +namespace-matches-repo +website +reachable +uptime-100% ~updated-41d-ago
- Derived from observable signals (official registry feed and our own credential-free probes); no code audit performed.

## Quality 79/100 (good)

### protocol: 75 (weight 25)

- warn `protocol.modern`: newest supported version is 2025-11-25; 2026-07-28 not supported, older versions are deprecated until 2027-07-28
- n/a `protocol.stateless`: only applies to 2026-07-28 servers
- pass `protocol.transport`: streamable HTTP
- n/a `protocol.list_ttl`: only applies to 2026-07-28 servers

### authorization: n/a (weight 15)

- n/a `auth.prm`, `auth.as_metadata`, `auth.cimd`: no remote uses OAuth
- n/a `auth.secret_in_url`: no templated URL

### tool hygiene: 71 (weight 30)

- pass `tools.descriptions`: every tool has a description
- pass `tools.description_length`: descriptions are concise
- pass `tools.schemas`: every tool has an object input schema
- fail `tools.annotations`: no tool declares readOnlyHint or destructiveHint, so clients cannot tell safe calls from risky ones
- fail `tools.directory_hints`: no tool declares all four of readOnlyHint, destructiveHint, idempotentHint and openWorldHint; missing: list_apis (readOnlyHint, destructiveHint, idempotentHint, openWorldHint); get_api_status (readOnlyHint, destructiveHint, idempotentHint, openWorldHint); get_uptime_history (readOnlyHint, destructiveHint, idempotentHint, openWorldHint); …
- pass `tools.token_cost`: about 1,085 tokens to load every tool
- pass `tools.api_dump`: tools are not a one-to-one API dump

### stability: 100 (weight 15)

- pass `stability.changes`: no tool changes in 30 days
- pass `stability.rug_pull`: no tool changed its meaning under the same name

### dependencies: n/a (weight 15)

- n/a `deps.known_vulns`, `deps.mcp_sdk_version`, `deps.resolvable`: no npm or PyPI package

- tools: 8, about 1,085 tokens to load them all
- tool set hash: fe3fae01665b0bb617ca88078bfd97ae
- badge: [![protogrid quality](https://protogrid.dev/badge/io.github.shibley/apistatuscheck.svg)](https://protogrid.dev/servers/io.github.shibley/apistatuscheck)
- Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed.

### Tool changes

_No tool definition changes recorded._

## Remotes

- https://apistatuscheck.com/api/mcp (streamable-http, auth none, reachable true, uptime30d 1)

## Packages

_none_

## Tools (8)

- `get_api_status`: Probe a monitored API endpoint at call time and return up/degraded/down with the response time. This is the tool to reach for when a user asks "is X down?" — it makes a real request rather than reading the hourly cache.
- `get_incident_history`: Real incidents a vendor published on its own status page, newest first, with start/end times, duration, severity, affected components and a link to the vendor’s incident page. Use this for "has X been flaky lately?" — it is the vendor’s own record, not our probes. Services without a public Statuspage endpoint return covered:false rather than an empty list.
- `get_uptime_history`: Uptime percentages, response-time stats and recorded data points for one API over a time range. History is retained for 30 days; an API added recently will have few or no data points, which reads as null percentages rather than 100%.
- `list_apis`: List the APIs and developer platforms this service monitors, optionally filtered by category. Statuses come from the most recently published monitor snapshot, not a live probe, and can be up to a day old — check monitorCheckedAt, and call get_api_status when the caller needs the status right now.
- `list_categories`: Category slugs and how many monitored APIs sit in each. Use the slugs with list_apis.
- `list_down_apis`: Everything the most recent monitor run found down or degraded, across all categories. Returns an empty list when the monitor snapshot is missing or stale — an empty list is therefore not proof that everything is healthy; check monitorLastRun.
- `rank_reliability`: Given several service slugs, return a scorecard ranked worst-first: incident count, total downtime minutes, mean time to resolve, and the longest incident over a window. Use this to answer "which vendor in my stack is least reliable?" — it compares services across vendors, which a vendor’s own monitoring tool cannot. Services with no archive are listed separately as uncovered instead of being ranked as flawless.
- `search_apis`: Find monitored APIs by name, slug, category or description. Use this to resolve a product name the user mentioned into the slug the other tools take.