Is this AI/dev API down? Is this model deprecated, what replaces it? Live status for ~40 APIs.
Scored across 5 tools
Each tool has a distinct resource+action scope (live provider status, single-model deprecation, daily digest, provider enumeration, filtered change feed), and every description explicitly names the sibling tools it should not be confused with. Boundaries like 'check_api_status vs check_model_deprecation vs list_recent_api_changes' are spelled out, so misselection is unlikely.
All names are snake_case with a clear verb prefix (check_*, get_*, list_*) followed by the target noun. The check_/get_/list_ prefix choices map semantically to the operation type, so the pattern is both consistent and informative.
Five tools exactly cover the domain's natural axes: one provider (status), one model (deprecation), a provider roster, a filtered event feed, and a daily rollup. Nothing is redundant and nothing feels padded or missing at the count level.
The read-only monitoring lifecycle is well covered: enumerate providers, check live health, check a model id, browse a filtered window, and get a consolidated digest. Minor gaps remain around bulk/multi-provider or multi-model checks and any alerting/subscription surface, but agents can work around these with repeated calls.
Check whether one AI or developer API provider (OpenAI, Anthropic, Gemini, Mistral, Groq, GitHub, Stripe, Cloudflare, Vercel, Supabase, Twilio, ~40 total) is up, degraded, or down right now. Use before calling that provider, or right after 5xx/429/timeouts, to choose retry, wait, or a fallback. Not for a model id (check_model_deprecation), the filtered change feed (list_recent_api_changes), or the daily rollup (get_digest). Returns summary, verdict (up|degraded|partially down|down|unknown), recommended_action, incidents, affected_components, checked_at, and freshness; status is rechecked about every 5 minutes. An unknown provider id returns 404 unknown_provider. Example: {"provider":"openai"}. Free within the daily quota, then $0.003 via x402. Alias: get_status.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes | Lowercase provider id from list_providers, not the display name. Examples: openai, anthropic, google-ai, mistral, groq, github, stripe, cloudflare. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description layers on non-annotation context: ~5-minute recheck freshness, a 404 unknown_provider error contract, and pricing (free within daily quota, then $0.003 via x402). It also enumerates the verdict domain, so the agent knows what it is receiving.
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?
Front-loads the purpose, then usage, then exclusions, then return shape and mechanics. Dense but every clause carries distinct information — no restatement of the title or name.
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?
There is no output schema, so the description carries the return contract itself and does so fully (summary, verdict enum, recommended_action, incidents, affected_components, checked_at, freshness). Combined with the error case, freshness window, alias, and pricing, an agent has everything needed to call and interpret the result.
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 is 3, but the description still adds meaning: the id must come from list_providers (not a display name), the sample invocation {"provider":"openai"}, and the failure mode for an unknown id. Useful reinforcement without syntax detail 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?
Opens with a specific verb+resource: check whether one named API provider is up, degraded, or down. It explicitly demarcates scope ('one ... provider' out of ~40) and names what it is not for, routing away from check_model_deprecation, list_recent_api_changes, and get_digest.
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?
Gives explicit when-to-use ('before calling that provider, or right after 5xx/429/timeouts'), the decision it supports ('choose retry, wait, or a fallback'), and explicit when-not-to-use with the three sibling alternatives named. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether one LLM model id is active, deprecated, or retired, plus its shutdown date and replacement, from that provider's deprecation page (OpenAI, Anthropic, Google, and other tracked LLM vendors). Use before hard-coding or calling a model, or when a call fails with model-not-found. Not for API uptime (check_api_status) and not for a retirement feed (list_recent_api_changes with kind model_retirement, or get_digest). Returns summary, verdict (active|deprecated|retired|unknown), recommended_action (keep_using|plan_migration|switch_now|verify_with_provider), replacement, shutdown_date, evidence, and freshness; pages are re-read every few hours. An unlisted id is verdict unknown, not an error; longer than 120 characters returns 400 bad_model_id. Example: {"model":"gpt-4-0613"}. Free within the daily quota, then $0.003 via x402. Alias: get_model (param id).
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Deprecated alias of model, only for the get_model tool name. Same 1–120 character API id. Ignored when model is also set. | |
| model | No | Exact API model id, not a display name or provider id. 1–120 characters; lowercased, and a leading models/ is stripped. Examples: gpt-4-0613, claude-3-opus-20240229, gemini-1.5-pro. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld/safe. Beyond that, the description discloses freshness (re-read every few hours), unlisted-id semantics (verdict unknown, not an error), the 120-char 400 bad_model_id behavior, quota/pricing, and returns. Very transparent, though freshness granularity and rate-limit details beyond quota are thin.
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?
Front-loaded purpose followed by usage, exclusions, returns, and edge cases. Dense but well organized; pricing/alias tail slightly crowds an otherwise tight 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?
No output schema, yet the description enumerates the return fields (summary, verdict, recommended_action, replacement, shutdown_date, evidence, freshness) and covers error semantics, freshness, and cost. Nothing needed to call it correctly 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%, documenting id/model aliasing, normalization (lowercasing, models/ prefix stripped), and that display names are invalid. The description adds essentially nothing the schema does not already state; baseline 3 applies.
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?
States a specific verb+resource (check whether a model id is active/deprecated/retired) and names the data source (provider deprecation pages). It explicitly distinguishes itself from siblings check_api_status and list_recent_api_changes/get_digest.
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?
Gives explicit when-to-use triggers ('before hard-coding or calling a model', 'when a call fails with model-not-found') and explicit exclusions with named alternatives for API uptime and retirement feeds.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one published daily breaking-changes digest: AI/dev API status flips, model deprecations and retirements, pricing-page edits, and breaking MCP server changes. Use for a once-a-day catch-up. For a filtered on-demand API feed with no MCP section, use list_recent_api_changes; for live up/down, check_api_status; for one model id, check_model_deprecation. Always free (no quota, no x402). Published once at 12:00 UTC as a frozen window since the previous issue (usually ~24h); not updated later. Omit date for the latest; a missing YYYY-MM-DD returns 404 {error:no_issue}. One issue per date, no paging. Returns {date, title, summary, window_start, window_end, published_at, markdown, data, url, sponsor:null}. data holds counts, status, open_now, model_changes, shutting_down_30d, pricing, deprecation_page_edits, and mcp (breaking, non_breaking, down, back, auth_broken, auth_fixed). markdown caps model rows, breaking MCP rows, and each MCP event kind at 30, 30, and 20; data is the full window.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Published issue date, YYYY-MM-DD (example 2026-10-14). Omit for the latest issue. A date with no stored issue returns 404 no_issue; issues appear at 12:00 UTC. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: publication cadence (12:00 UTC, frozen window ~24h, never updated later), cost profile (free, no quota, no x402), failure behavior (404 {error:no_issue}), and no paging. This is exactly the behavioral detail structured fields cannot carry.
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?
Purpose and sibling routing are front-loaded, then availability semantics, then return shape — a logical order. It is dense and long, and the 404/no_issue statement repeats the schema description nearly verbatim, which is the only real 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?
No output schema exists, and the description compensates by naming every top-level return field and the sub-fields of data, plus the markdown truncation caps (30/30/20) versus the full data window. Combined with cadence and error semantics, an agent has everything needed to call and interpret it.
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% (pattern, example, description), so the baseline is 3; the description goes further by stating the omit-for-latest default, the 404 error payload for an unstored date, and the one-issue-per-date/no-paging constraint. It stops short of adding anything about date range bounds or timezone interpretation beyond the 12:00 UTC note.
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?
States a specific verb and resource ('Read one published daily breaking-changes digest') and enumerates the content domain (status flips, deprecations, pricing edits, breaking MCP changes). It also names the three sibling tools it is not, so an agent can disambiguate without opening any schema.
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 scopes the use case ('once-a-day catch-up') and routes the agent to alternatives by condition: list_recent_api_changes for a filtered on-demand feed with no MCP section, check_api_status for live up/down, check_model_deprecation for a single model id. When-to-use and when-not-to-use are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every AI and developer API provider Upstream tracks (~40) with id, name, category, current state, checked_at, and status page. Use to pick a provider id for check_api_status, or for one all-providers health pass. Not for one provider's incidents (check_api_status) and not for what changed (list_recent_api_changes or get_digest). No parameters. Always free; does not spend the daily quota. State is refreshed about every 5 minutes. Returns {count, providers:[{id, name, category, state, checked_at, status_page}]}; state is operational, degraded, partial_outage, major_outage, maintenance, or unknown.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real operational context beyond annotations: always free, does not spend the daily quota, and refreshes every ~5 minutes. Annotations already cover readOnly/idempotent/openWorld, so the quota and freshness facts are the valuable additions. Return shape is described but no pagination behavior is needed for a fixed ~40-item list.
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?
Front-loads the core action and scope, then routes exclusions, then cost/freshness, then return shape. Dense but every sentence earns its place; no redundant restatement of the name.
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?
No annotations gaps and no output schema, so the description carries return shape, cost, freshness, and routing rules, which is everything an agent needs to invoke this list tool correctly. Nothing material 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?
Zero parameters, so baseline is 4. The description confirms 'No parameters', which is consistent and helpful, and it fully documents the returned fields even though that is technically output rather than parameter semantics.
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?
States a precise verb (List) and resource (API providers ~40) with the exact fields returned. It distinguishes itself from check_api_status, list_recent_api_changes, and get_digest by name, so an agent can route without opening a schema.
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?
Gives explicit when-to-use (pick a provider id, one all-providers health pass) and explicit when-not (not for incidents, not for changes), naming the correct alternatives for each excluded case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the on-demand feed of recent AI and developer API changes (status flips, deprecation-page edits, model retirements, pricing-page edits). Use for a chosen window, one provider, or one kind, when explaining sudden breakage. Not for live up/down (check_api_status) and not for the once-a-day digest, which also covers MCP server breakage (get_digest). Returns summary, count, freshness, and changes[] with provider, kind, title, detail, source, and at, newest first. Status rows arrive within about 5 minutes; doc-page rows every few hours. A limit above 500 is clamped to 500; an unknown provider returns an empty list, not an error. Example: {"provider":"anthropic","kind":"model_retirement"}. Free within the daily quota, then $0.01 via x402. Alias: get_changes.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Optional type filter. status = provider state flips; deprecations = deprecation-page line edits; model_retirement = a model id became deprecated or retired; pricing = pricing-page line edits. Omit for all four. | |
| limit | No | How many changes to return, newest first. Positive integer. Omit for 100. | |
| since | No | Exclusive lower bound compared to each change's at. ISO 8601 UTC. Example: 2026-10-01T00:00:00Z. Omit for 7 days ago. | |
| provider | No | Optional lowercase provider id from list_providers, e.g. openai or anthropic. Omit for every provider. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantial behavior beyond them: freshness SLAs (status rows ~5 min, doc rows every few hours), limit clamping at 500, unknown-provider-returns-empty-not-error, and pricing/quota via x402. That is exactly the extra context annotations cannot express.
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?
Front-loaded with purpose and routing, and every sentence carries information (types, alternatives, return shape, freshness, clamping, pricing). It is dense and a touch long, packing return fields, quotas, and an alias into one paragraph, but there is little wasted verbiage.
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 no output schema, the description compensates by enumerating the return shape (summary, count, freshness, changes[] with provider, kind, title, detail, source, at), plus ordering, freshness, and edge-case behavior. An agent has everything needed to call and interpret it.
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 baseline is 3; the description still adds value by giving a concrete combined example call and by documenting the limit clamping behavior, which the schema does not. It doesn't go further on `since` semantics beyond what the schema already states.
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?
States a specific verb+resource ('List the on-demand feed of recent AI and developer API changes') and enumerates the covered event types. It also distinguishes itself from siblings by naming check_api_status and get_digest explicitly, so an agent can select it without opening other schemas.
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?
Gives explicit when-to-use ('a chosen window, one provider, or one kind, when explaining sudden breakage') and when-not ('Not for live up/down ... and not for the once-a-day digest'), naming the alternatives. This is close to ideal routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_api_status1 field changedInput schema / properties / provider / descriptionPrevious value: -"Provider id (lowercase). Examples: openai, anthropic, google-ai, mistral, groq, github, stripe, cloudflare. Full list: list_providers."New value: +"Lowercase provider id from list_providers, not the display name. Examples: openai, anthropic, google-ai, mistral, groq, github, stripe, cloudflare."check_model_deprecation6 fields changedInput schema / properties / id / descriptionPrevious value: -"Deprecated alias of model."New value: +"Deprecated alias of model, only for the get_model tool name. Same 1–120 character API id. Ignored when model is also set."Input schema / properties / id / maxLengthAdded value: +120Input schema / properties / id / minLengthAdded value: +1Input schema / properties / model / descriptionPrevious value: -"Model id as used in the API call. Examples: gpt-4o, claude-3-opus-20240229, gemini-1.5-pro."New value: +"Exact API model id, not a display name or provider id. 1–120 characters; lowercased, and a leading models/ is stripped. Examples: gpt-4-0613, claude-3-opus-20240229, gemini-1.5-pro."Input schema / properties / model / maxLengthAdded value: +120Input schema / properties / model / minLengthAdded value: +1get_digest3 fields changedInput schema / properties / date / descriptionPrevious value: -"YYYY-MM-DD; omit for the latest issue"New value: +"Published issue date, YYYY-MM-DD (example 2026-10-14). Omit for the latest issue. A date with no stored issue returns 404 no_issue; issues appear at 12:00 UTC."Input schema / properties / date / examplesAdded value: +[
+ "2026-10-14"
+]Input schema / properties / date / patternAdded value: +"^\\d{4}-\\d{2}-\\d{2}$"list_recent_api_changes8 fields changedInput schema / properties / kind / descriptionPrevious value: -"Optional change type filter"New value: +"Optional type filter. status = provider state flips; deprecations = deprecation-page line edits; model_retirement = a model id became deprecated or retired; pricing = pricing-page line edits. Omit for all four."Input schema / properties / kind / examplesAdded value: +[
+ "model_retirement"
+]Input schema / properties / limit / descriptionPrevious value: -"Max items, default 100, max 500"New value: +"How many changes to return, newest first. Positive integer. Omit for 100."Input schema / properties / limit / examplesAdded value: +[
+ 100
+]Input schema / properties / provider / descriptionPrevious value: -"Optional provider id, e.g. openai"New value: +"Optional lowercase provider id from list_providers, e.g. openai or anthropic. Omit for every provider."Input schema / properties / provider / examplesAdded value: +[
+ "openai",
+ "anthropic"
+]Input schema / properties / since / descriptionPrevious value: -"ISO 8601 timestamp; default 7 days ago. Example: 2026-10-01T00:00:00Z"New value: +"Exclusive lower bound compared to each change's at. ISO 8601 UTC. Example: 2026-10-01T00:00:00Z. Omit for 7 days ago."Input schema / properties / since / examplesAdded value: +[
+ "2026-10-01T00:00:00Z"
+]check_api_statuscheck_model_deprecationget_changesget_modelget_statuslist_recent_api_changesget_changesget_digestget_modelget_statuslist_providersLive status, API pricing and rate limits for ChatGPT, Claude, Gemini, Cursor and 42+ AI tools.
Real-time status for 75+ AI services (OpenAI, Anthropic, Cursor). No auth, CORS-enabled.
Is GitHub, npm, Cloudflare or your AI provider down right now? 20 status pages, one call.
Real-time status & uptime monitoring for 294 popular APIs — is it down, and how reliable?
Add one secure layer between your agents and this server.
