Check real-time uptime and incident status for 285 APIs and cloud services.
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.3/5 across 8 of 8 tools scored.
Each tool targets a distinct aspect of API status monitoring: live probe vs. snapshot status, vendor incidents vs. uptime stats, listing vs. searching. No two tools are easily confused.
All tool names follow a consistent verb_noun pattern with snake_case (get_, list_, search_, rank_). The verbs align with the action performed, making the set predictable.
With 8 tools, the server is well-scoped for its purpose. Each tool fills a necessary role without redundancy or bloat.
The domain of checking API status is fully covered: live probing, historical incidents, uptime stats, querying by category, identifying down APIs, and comparing reliability. No critical gaps are evident.
get_api_statusCheck an API right nowAInspectProbe 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.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | API slug, e.g. "openai". Use search_apis to resolve a name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It clearly states this tool performs a live probe at call time and returns a status plus response time, which is critical behavior beyond the schema. However, it does not mention potential side effects like latency or rate limiting, leaving minor gaps.
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 two sentences long, front-loaded with the core action and result, then immediately provides a practical usage example. Every word adds value with no waste or 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?
For a simple, real-time probe tool with one parameter and no output schema, the description is complete: it explains the return values (up/degraded/down, response time), the live nature, and the use case. No important context is missing.
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% and the single parameter 'slug' is already well-described in the schema with an example and reference to search_apis. The description does not add parameter-level details, but the schema fully covers it, so the baseline of 3 is appropriate.
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 the specific verb 'probe' and clearly identifies the resource ('monitored API endpoint') and the action ('return up/degraded/down with the response time'). It explicitly distinguishes itself from sibling tools by contrasting with 'reading the hourly cache,' making the tool's purpose unambiguous.
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 direct usage guidance: 'This is the tool to reach for when a user asks "is X down?"' and explicitly notes it 'makes a real request rather than reading the hourly cache,' which implies when not to use it (when a cached answer is acceptable). This effectively differentiates from sibling tools like list_down_apis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_incident_historyGet a service’s published incident historyAInspectReal 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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max incidents (default 25). | |
| window | No | Time window: 7d, 30d, 90d, 180d, 365d, all (default 90d). | |
| service | Yes | API slug, e.g. "openai". Use search_apis to resolve a name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses ordering (newest first), the data source (vendor's status page), and the special case of returning covered:false for services without a Statuspage endpoint. Missing details like pagination or rate limits, but the disclosure is substantive for a read-only list tool.
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 two sentences, front-loaded with the core behavior and followed by use case and edge case. No filler or redundancy; every clause adds useful information.
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?
For a 3-parameter tool without an output schema, the description provides a clear picture: what the data is, the source, ordering, fields, and a notable edge case. It could mention pagination limits or the exact response structure, but given the absence of an output schema, the field list helps set expectations. Overall, it is reasonably complete.
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 the baseline applies. The description does not add any parameter-specific semantics beyond the schema; it mentions the fields returned but not how limit/window/service behave. The schema already documents the default values and the hint to use search_apis for resolving names, so the description adds no extra value here.
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 identifies the tool's function: retrieving real incidents published by the vendor on its status page. It lists specific data points (start/end times, duration, severity, affected components, link) and distinguishes itself from probe-based tools by stating "it is the vendor’s own record, not our probes."
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 a concrete use case ("has X been flaky lately?") and clarifies the data source distinction from own probes, implicitly steering users to other tools for probe-based data. It also explains the edge case behavior for services without a public Statuspage endpoint. However, it does not explicitly name alternative sibling tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_uptime_historyGet retained uptime historyAInspectUptime 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%.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | API slug, e.g. "openai". | |
| range | No | Window to return data points for (default 24h). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains data retention (30 days), the impact of recently added APIs (few/null data points), and clarifies that null percentages are expected rather than 100%. This adds valuable context beyond the schema, though it stops short of describing return structure or potential errors.
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 two sentences long, front-loaded with the core output (uptime percentages, response-time stats, data points) and followed by a valuable caveat about retention. No words are wasted, and every sentence contributes to understanding the tool's behavior.
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 simplicity (2 parameters, no output schema), the description provides sufficient context for basic use. It covers what the tool returns and a key edge case (null percentages for recent APIs). However, it leaves some ambiguity about the exact format of response-time stats and does not explicitly state the default range, which the schema handles. Overall, it is complete for typical usage.
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 provides 100% coverage of both parameters (slug and range), so the description adds minimal semantic value. It mentions 'one API' and 'time range', which map to the parameters, but does not elaborate on allowed values or defaults beyond what the schema's enum and descriptions already state. Baseline 3 is appropriate.
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 that the tool returns uptime percentages, response-time stats, and recorded data points for one API over a time range. This specific verb-resource pairing distinguishes it from siblings like get_api_status (which likely returns current status) and list_apis (which lists APIs), making its purpose unmistakable.
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 implies the tool is for historical uptime data but does not explicitly mention when to use it over alternatives like get_api_status or list_down_apis. It provides no exclusions or alternative recommendations, though the context of 'history' and 'one API' gives a reasonable hint. This is adequate but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_apisList monitored APIsAInspectList the APIs and developer platforms this service monitors, optionally filtered by category. Statuses are from the most recent hourly monitor run, not a live probe.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 25). | |
| category | No | Category slug to filter by, e.g. "ai" — omit for all categories. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that statuses are from the most recent hourly monitor run, not a live probe, which is key behavioral context. The verb 'List' also implicitly indicates a read-only operation.
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, front-loaded with the verb 'List', and no filler. The caveat about data freshness adds value without bloating the description.
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?
For a simple list tool with no output schema, the description conveys purpose, optional filtering, and a critical data freshness caveat. Sibling tools are easily distinguishable, making the description sufficient for tool selection.
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 description coverage is 100%, with both parameters already described. The tool description only reiterates the category filter without adding new syntax or behavior 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?
Description states it lists APIs and developer platforms with optional category filtering, using a specific verb and resource. This clearly distinguishes from siblings like get_api_status (specific status) and list_down_apis (only down services).
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 clarifies the data freshness caveat ('not a live probe'), implying when it is appropriate to use. It doesn't explicitly name alternatives, but the context is clear enough for a list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_categoriesList API categoriesAInspectCategory slugs and how many monitored APIs sit in each. Use the slugs with list_apis.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the output (slugs and counts) but does not explicitly confirm it's read-only, nor does it mention ordering, pagination, or error behavior. For a trivial listing tool with no parameters, a 3 is appropriate as the description gives basic transparency but lacks explicit safety or behavioral details.
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 two sentences with no wasted words. The first sentence states the return value, and the second gives usage direction. Every word contributes to the intended meaning, making it highly 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?
Given the tool's simplicity (zero parameters, no output schema, read-only by nature), the description fully covers the return value and provides a usage context via the sibling tool reference. There is no additional complexity requiring more 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?
The input schema has zero properties, so there are no parameters to document. According to the rubric, a 0-parameter tool gets a baseline of 4. The description adds no parameter details, but none are needed.
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 returns 'Category slugs and how many monitored APIs sit in each', specifying both the resource (categories) and the output (slugs and counts). This distinguishes it from sibling tool list_apis, which lists APIs rather than categories. The verb 'List' is implicit in the name and title, making the purpose unambiguous.
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 instructs to 'Use the slugs with list_apis', giving a concrete workflow context and a reason to call this tool. It does not state exclusions or alternative scenarios, but for a simple zero-parameter listing tool, this provides clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_down_apisList APIs currently down or degradedAInspectEverything 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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses a key behavior: an empty list can indicate a missing or stale snapshot, not health, and directs users to check monitorLastRun. This adds meaningful context beyond the tool name.
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 two sentences long and front-loads the core purpose, followed by a necessary caveat. Every clause earns its place and no redundant information is present.
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?
For a simple, parameterless list tool, the description explains the data source (monitor run), the scope (all categories), and the critical caveat about empty lists and stale snapshots. This is complete for the tool's complexity.
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 tool has zero parameters and schema coverage is complete, so there is nothing to compensate for. The baseline for zero-parameter tools is 4, and the description adds no parameter-specific information, which is acceptable.
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?
Clearly states the tool lists everything found down or degraded in the most recent monitor run, across all categories. The verb is implied by the name, and the description distinguishes it from sibling tools by specifying the monitor-run scope.
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 context about the most recent monitor run and warns about empty lists when the snapshot is stale, which helps interpret results. However, it does not explicitly direct users to alternatives or state when to use this tool over list_apis or get_api_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rank_reliabilityRank vendors by reliabilityAInspectGiven 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.
| Name | Required | Description | Default |
|---|---|---|---|
| window | No | Time window: 7d, 30d, 90d, 180d, 365d, all (default 90d). | |
| services | Yes | API slugs to compare, e.g. ["openai","anthropic","vercel"]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses a key behavioral quirk: 'Services with no archive are listed separately as uncovered instead of being ranked as flawless.' It also lists the output metrics, but it does not specify the exact ranking algorithm or how the window affects each metric, leaving some ambiguity.
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 at just two sentences, front-loaded with the core function and output. The first sentence defines the return value, the second gives usage guidance and a special case. No filler words; every sentence 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 two parameters and no output schema, the description covers the essential output (scorecard with four reliability metrics) and mentions a notable edge case. However, it does not fully specify the ranking order ('worst-first' could be by downtime or incident count) or response format, leaving some gaps for a tool of this simplicity.
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 provides descriptions for both parameters (services array and window enum), so coverage is 100%. The description adds minimal semantic value beyond the schema, mostly reinforcing that services are slugs and referring to 'a window'. This is sufficient but not exceptional, aligning with the baseline for high 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's function: 'Given several service slugs, return a scorecard ranked worst-first' and enumerates the metrics (incident count, downtime, MTTR, longest incident). It also distinguishes itself from siblings by emphasizing cross-vendor comparison, which vendor monitoring tools cannot do.
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 provides a use case: 'Use this to answer "which vendor in my stack is least reliable?"' and notes that it compares services across vendors, differentiating it from single-vendor monitoring alternatives. Although no sibling tools are named, the context makes the appropriate usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_apisSearch monitored APIsAInspectFind 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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 25). | |
| query | Yes | Free-text query, e.g. "openai" or "payments". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly implies a non-destructive search operation, but it does not disclose the return format, whether results are exact or fuzzy matches, or pagination behavior. This leaves some behavioral ambiguity.
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 two sentences, front-loaded with the core action and resource, and the second sentence provides practical context without waste. It is compact and informative.
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?
For a simple search tool with 100% schema coverage and no output schema, the description is sufficient: it states what is searched, the resolution purpose, and the limit parameter is already documented. Sibling tools provide additional context. The main gap is a lack of detail about the result structure, but that is not critical for selection.
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%: both 'query' and 'limit' are described with examples, defaults, and constraints. The description adds that query can match name/slug/category/description, which reinforces the schema but doesn't add new parameter semantics. This is the baseline 3.
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 action ('Find') and the resource ('monitored APIs'), and enumerates the searchable fields (name, slug, category, description). It also distinguishes the tool from sibling list tools by explaining that it resolves a product name into the slug used by 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?
The description explicitly says 'Use this to resolve a product name the user mentioned into the slug the other tools take,' which gives a concrete use case and implies that alternatives require the slug. However, it doesn't explicitly name sibling tools or state when not to use it, so it stops short of a 5.
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.