Add API Status Check

[shibley]

Adds API Status Check to MCP Servers and Data Connectors.

Disclosure up front: this is a self-submission. I maintain it. Flagging the things a maintainer would otherwise have to dig for, below.

Why this section, next to CorpusIQ rather than over it

CorpusIQ connects agents to Stripe, GA4, Shopify, QuickBooks and HubSpot. This answers the question that shows up the moment one of those calls fails: is the vendor down, or is the agent's own code wrong? An agent that can't tell those apart retries a broken request, or gives up on a working one. The two entries compose — one reaches the API, this one adjudicates the failure.

It is deliberately not in Monitoring and Observability. Everything in that section watches the agent (LangSmith, Helicone, AgentOps, Langfuse traces and evals). This watches the third parties the agent depends on, and never touches your infrastructure — no endpoints of yours are registered, nothing is instrumented.

The claim, as a call you can run

curl -s -X POST https://apistatuscheck.com/api/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call",
       "params":{"name":"get_api_status","arguments":{"slug":"stripe"}}}'

Returns a real probe made at call time, with responseTimeMs and a checkedAt. 285 vendors in the catalogue; search_apis resolves a product name a user typed into the slug the other tools take.

Two things to know before you merge

1. Not every tool is live-probed, and the distinction is load-bearing. get_api_status probes at call time. list_apis and list_down_apis read the last hourly monitor run and carry a timestamp saying so. The product's own marketing copy says "every 60 seconds" — that is wrong about the background monitor, and I'd rather you hear it here than find it.

2. A probe-accuracy bug was fixed today, before opening this. Probing all 285 endpoints turned up 37 vendors — Stripe, Supabase, Anthropic, Gemini, Cloudflare, Datadog among them — reported degraded when they were healthy: an unauthenticated HEAD drew a 404 or 400, and the reachability check only allow-listed 401/403/405/429. Any status under 500 means the vendor answered. Fixed, and re-verified against the same 285 endpoints (272 up / 2 degraded / 11 down, with one genuine HTTP 500 still correctly flagged). I mention it because "live-probes 285 vendors" is the entry's whole claim, and it was 13% wrong this morning.

Housekeeping

• Placed after CorpusIQ rather than alphabetically first — CONTRIBUTING.md doesn't specify an order, and putting my own submission at the top of the section seemed like the wrong default. Happy to move it.
• Format matches [Name](link) - Description.; description doesn't open with "A"/"An"; single item, single PR.
• Free tier, no signup, no key required for the MCP endpoint.

Close it without ceremony if a commercial self-submission isn't what this section is for.

[Scottcjn]

Received, and queued for review — apologies for the silence up to now.

This is a maintainer-side backlog rather than any verdict on your contribution. We
had a large number of open PRs with no reply on them at all, which is our failure to
manage, not a signal about your work. Yours is in the queue and will get a real
review with a real decision.

I'm not going to give you a date I might miss. What I can tell you:

• Reviews run oldest-first.
• If this PR has gone stale against main, say so and I'll prioritise closing it so
  the queue reflects what you actually still want landed.
• If you're submitting this for bounty credit, link the bounty issue in a comment —
  several contributions are eligible and we'd rather pay you than have you wonder.

Thanks for your patience, and for the work.