Ask Claude If Your Stack Is Down: Statusfield's Read-Only API and Hosted MCP Server

Last week I was heads-down in Claude Code when a deploy started failing.

My first question wasn't "what did I just break?" It was "is GitHub having a moment again?"

And to answer it I did what I've always done: alt-tab to a browser, load a status page, squint at it, alt-tab back. Every single time.

That round trip is small. It's also the exact context switch you don't want in the middle of an incident — the moment you're asking "is it us or is it them?", the answer should come to you, not send you tab-hunting.

So we shipped two ways to get the answer without leaving your tools.

The Statusfield API is a read-only REST interface to the thousands of vendor status pages we already aggregate; the hosted MCP server exposes that same catalog to AI tools like Claude, so an agent can check whether a service is down without you opening a browser.

Both are live now on the Hobby plan and up.

What shipped

Two things, sharing one sf_ API key:

• A read-only REST API (/api/v2/*) — query your monitors, search the catalog, or pull the list of everything currently down, with a Bearer token.
• A hosted MCP server (/api/mcp) — four read-only tools that let Claude Desktop or Claude Code query Statusfield directly, including your own monitor list.

That's the whole release. It is deliberately read-only, and I'll be honest about what that does and doesn't cover further down.

Why we built it

Statusfield has always done one thing: watch the third-party services your business depends on and tell you when they go down, so you hear it from us instead of from an angry customer. We aggregate thousands of status pages into one alert stream, normalized down to the component — "GitHub Actions", not just "GitHub"; "us-east-1", not just "AWS".

To be clear about what that is and isn't: we relay the official vendor status — we don't beat the vendor to it. When Stripe's status page flips a component to degraded, we mirror that, fast and faithfully. The value is consolidation and fidelity across a lot of vendors, not a crystal ball.

Until now, all of that lived behind a dashboard and a notification. Useful when an alert fires. Less useful when you have the question — mid-deploy, in a terminal, inside an agent loop — and you want to pull the answer yourself.

So we made the same data programmatic, and then AI-native. The status of thousands of vendors is now something a script can poll and an agent can read.

REST quickstart

1. Get a key

In the app, go to Integrations → API Keys and create one. It starts with sf_, and it's shown exactly once — copy it then.

2. Call it

Ask what's down across the whole catalog right now:

curl -H "Authorization: Bearer sf_your_key" \
  https://statusfield.com/api/v2/outages

Or scope it to just the services you monitor:

curl -H "Authorization: Bearer sf_your_key" \
  "https://statusfield.com/api/v2/monitors?filter=outages"

The endpoints

Every key is rate-limited per second and per minute, and each plan carries a monthly request quota. Responses set X-RateLimit-* and X-Quota-* headers so you can see exactly where you stand; the numbers per plan live on the pricing page.

MCP quickstart

The MCP server is the same catalog, wired for AI tools. Add it to Claude with one command:

claude mcp add --transport http statusfield https://statusfield.com/api/mcp --header "Authorization: Bearer sf_your_key"

That's it — same sf_ key, no separate signup. It exposes four tools:

A worked example

Once it's connected, you can ask the question that started this post — from inside Claude Code, without touching a browser:

You: Is anything I depend on down right now?

Claude: (calls list_my_down_services) Of the services you monitor, GitHub Actions is showing degraded performance — everything else is operational. (reads your package.json, spots two dependencies you don't monitor, calls get_service_status for each) Stripe and Vercel are fine too. Your failing deploy lines up with the GitHub Actions incident — not your code.

That last line is the whole point: Claude answered "is it us or them?" with real vendor status, and you never left the editor.

How the tools split the work: three of the four read the shared catalog — they answer "is Stripe down?" for any service in the catalog, whether you monitor it or not. The fourth, list_my_down_services, reads your own monitor list and answers "which of my services is down?" directly. For your full monitor list — healthy ones included — that's the REST GET /api/v2/monitors endpoint.

Honest scope: this is a read-only v1

One thing I want to be upfront about: v1 is strictly read-only. The four MCP tools and every REST endpoint only read status — there's no create_monitor, no write access, no way for an agent to change your account.

We started narrow on purpose:

• Read-only is the safe default for an agent. An LLM calling list_outages can't misfire. An LLM with a create_monitor or delete_monitor tool can, and I'd rather earn write access than ship it in v1.
• The catalog is the 90% question. "Is this vendor down?" is what people actually ask an agent mid-incident. That's what we built first, and built to be accurate.
• The sf_ key already gates it correctly. Same auth, same rate limits, same quota as REST — so when we do add write tools, the plumbing is already load-bearing and tested, not bolted on.

If you want a fast, read-only "is my stack up?" that plugs into Claude in one command, that's this. If your workflow needs an agent that manages monitors, that's on the roadmap — not shipped.

Write tools are the natural next step. I'd rather ship them once they're safe than rush them.

FAQ

Is the API read-only? Yes. v1 is strictly read — you can query status, you can't change anything. No write endpoints yet.

Which plans include the API and MCP server? The Hobby plan and up. They're off on the free plan. Exact request limits per plan are on the pricing page.

Does the MCP server know which services I monitor? Yes. list_my_down_services reads your workspace's saved monitors and reports which are currently down or degraded — that's the tool Claude calls when you ask "is anything I monitor down?". The other three tools query the shared catalog. Your full monitor list, healthy ones included, is behind the REST GET /api/v2/monitors endpoint.

Can Claude create or change monitors through the MCP? Not in v1. All four tools are read-only. Write tools are on the roadmap, not shipped.

Does the API detect outages faster than the vendor's own status page? No — and we never claim it does. We relay the official vendor status, consolidated across thousands of services and down to the component. The API and MCP make that same data programmatic; they don't get there first.

The Bottom Line

If you depend on a handful of vendors and you're happy alt-tabbing to a status page a few times a month, you don't need this. That's the honest answer, same as it's always been.

But if you're already in Claude Code or a script when the question hits — "is it us or is it them?" — pulling the answer without a browser round trip is worth the one-line setup.

The API and hosted MCP server are available on the Hobby plan and up. Turn them on, then grab a key from Integrations → API Keys and paste the claude mcp add command above. New here? Start monitoring your vendors free first — then upgrade when you want them programmatic.

Building something on the API or MCP server? I'd like to hear what you're wiring it into — support@statusfield.com.