The PulsAPI MCP Server: Live Vendor Status Inside Your AI Agent

PulsAPI now runs a remote Model Context Protocol server at https://www.pulsapi.com/api/mcp. Point Claude Code, Claude Desktop, Cursor, VS Code, Codex, or any other MCP client at that one URL and the agent gains five tools for reading live vendor status across the 2,463 providers PulsAPI tracks. There is no API key to generate and nothing to paste into a config file: the client discovers the server, registers itself, opens a browser, and you approve it once.

The short version, for readers who want to stop here. Transport is Streamable HTTP, JSON-RPC 2.0 over a single POST endpoint, with no session handshake because the server is stateless. The protocol revision is 2025-06-18. Authorization is OAuth 2.1 with authorization code, PKCE, and dynamic client registration. Every tool requires a token, and the account behind that token needs the Pro plan or above. Connection recipes for each client live on the developer hub, and the reference is in the MCP integration docs.

This article covers what the five tools do, how to connect each client, why connecting is a browser flow and not a key, and what the server deliberately does not do. If you want the specifications and the failure modes instead, the engineering write-up is what OAuth 2.1 actually requires from a remote MCP server.

Ask any frontier model whether a vendor is currently down and it will answer. That is the problem. A language model's weights are frozen at a training cutoff, so its beliefs about infrastructure are a snapshot of the open web from some months before you asked. It has no way to distinguish knowing something from having once known something like it, and outage state is the most perishable fact in an operations workflow: the useful half-life of "Cloudflare is degraded" is measured in minutes.

The obvious workaround, letting the agent fetch the vendor's status page itself, fails on a different axis. Status pages are not a format. Some vendors publish a clean JSON summary, some publish an RSS feed that is not date-ordered, some publish a JavaScript application with the data side-loaded, and a meaningful share publish nothing machine-readable at all. An agent handed a raw status page also has to guess at vocabulary that is not standardised between vendors, where one provider's "degraded" is another's "partial outage". We measured how wide that spread is in the status page transparency report.

A tool call closes both gaps in one step. The agent asks a question in a fixed schema and gets back a normalised answer that was fetched from the vendor minutes ago, not recalled from training data. The model stops being the source of the fact and becomes the thing that decides which fact to ask for.

The tool surface is intentionally small. Five tools with narrow, obvious boundaries beat fifteen overlapping ones, because an agent choosing between tools is doing a classification task and every near-duplicate makes it harder. Each one maps to a question an engineer already asks during an incident.

All five are read-only. None of them can subscribe you to anything, change an alert rule, modify a dashboard, or write to your workspace. The boundary is deliberate rather than a phase-one limitation, and the limits section below says why.

Four clients speak Streamable HTTP and run the authorization flow themselves, so they need the URL and nothing else. Clients that can only launch a local process go through the community stdio bridge, which performs the same flow on their behalf and caches the token locally. Either way you are copying a URL and nothing secret, which is why the config file is safe to commit.

The one case where an API key is still correct is CI. A build agent has no browser and nobody to click Approve, so the flow cannot complete. For that, a scoped key carrying the mcp:invoke scope goes in an X-API-Key header. Everything with a person attached should use the browser flow.

The first version of this server used API keys, and the keys were the worst part of it. A key is a bearer secret that has to be copied out of a dashboard, pasted into a config file, and then kept out of a commit. In practice it ends up in three editors, a shell history, and at least one screenshot in a support thread. Revoking it means rotating a secret and finding every copy, which is exactly the work nobody does at the moment they realise they need to.

OAuth moves that problem somewhere it can actually be solved. The client registers itself dynamically, so nobody provisions anything ahead of time. You approve a specific client for a specific scope on a consent screen you can read. The token it receives is bound to this server as its audience, so it is useless anywhere else even if it leaks. And withdrawing access is a button in your settings instead of a secret rotation, because the grant lives on our side of the connection instead of in your dotfiles.

The lifetimes are short on purpose. An authorization code lives 60 seconds, because it travels through a browser URL and is worth almost nothing for almost no time. An access token lives one hour. A refresh token lives 30 days and rotates on every use, and if an already-spent refresh token is presented again the whole chain is revoked: two parties holding the same token means one of them took it, and there is no way to tell which one is calling.

One behaviour tends to get reported as a bug. If your plan lapses after a client has connected, calls start returning 403, and not the 401 you might expect. That is deliberate. The caller proved who it is, so re-authenticating will not help, and a 401 would send a well-behaved client into a pointless re-authorization loop. The 403 says the identity is fine and the entitlement is not.

The useful test for a tool like this is not whether it answers questions. It is whether it removes a step from a workflow somebody is doing at 03:00.

Take the most common third-party triage question: checkout is failing, and nobody yet knows whether that is us or the payment provider. Without the tool, an engineer opens the vendor's status page, reads a headline that covers the whole product, then goes hunting for whether the component and region they actually use are implicated. That last part is where the minutes go, because the headline is usually the least specific thing on the page.

With the tool connected, the agent can chain get_service_status for the headline and get_component_status for the breakdown in a single turn, then compare the affected component against the dependency map already in the repository. The output is not "Stripe is having problems". It is that the vendor reports degraded card authorisations, your checkout path uses that component, and your webhook consumer does not. A status page headline cannot produce that sentence, and it is the sentence the incident channel actually needs.

It also fixes a quieter failure. An agent with no live source does not decline to answer, it guesses, and a confident wrong answer about whether a vendor is down is worse than no answer at all, because somebody acts on it. If you are designing runbooks around this, the pattern drops straight into the third-party outage runbook.

Every tool is read-only, and every tool reads public vendor status. There is no tool that can see your dashboards, your alert rules, your team, or your subscriptions, and there is no write path at all. An agent is a program acting on inferred intent, and the blast radius of a mistaken read is a wrong answer, while the blast radius of a mistaken write is a changed production alert rule. Those are not comparable risks, so they do not get the same door.

Results are only as good as what each vendor publishes. Where a provider publishes nothing parseable, PulsAPI falls back to a direct reachability check, which is a weaker global up-or-down signal and not per-component detail. The response reflects that honestly instead of inventing component granularity that was never published. The gap between what vendors claim and what they disclose is the subject of vendor status page accuracy.

MCP access sits on the Pro plan and above, alongside the other programmatic surfaces. The pricing page has the current tiers. Every connected client, and the ability to disconnect any of them, is listed in Settings, MCP server.

Do I need an API key? No, not for any client with a browser. The client registers itself and sends you through a consent screen, and the token is stored by the client, not by you. Keys remain the right answer for headless callers such as CI jobs, where there is nobody available to approve a browser prompt.

Which MCP clients are supported? Any client that speaks Streamable HTTP, which today includes Claude Code, Claude Desktop, Cursor, and VS Code in Copilot agent mode. Clients restricted to stdio, such as Codex CLI, connect through the mcp-remote bridge, which performs the same flow and caches the token locally. The server does not special-case any vendor.

Can the server see my dashboards or alert rules? No. All five tools read public vendor status data, the same information the website serves. There is no tool that reads workspace data and no tool that writes anything at all.

What happens if my plan lapses? Tool calls come back 403, because the caller is authenticated and simply not entitled. Well-behaved clients surface that as a permission error instead of retrying the authorization flow. The connection itself stays intact and resumes working when the plan does.

Is there still a free anonymous tier? No. An earlier version of this server exposed four tools with no credential at all. That tier has been removed: every request now carries a token, which is what makes per-account rate limiting, revocation, and an audit trail possible at all. The reasoning is in the OAuth build log.

How fresh is the data? It reflects the most recent probe of each vendor's status source. High-demand services refresh several times faster than the long tail, and anything mid-incident or freshly changed is escalated to the fast tier automatically, so recoveries surface quickly instead of waiting for a flat sweep to come around.