System status

What the success rate counts. The denominator is requests our MCP endpoint accepted and attempted to serve. It deliberately excludes requests we declined on purpose: calls with an invalid or missing token, calls refused for exceeding a plan's rate limit, calls to a tool the workspace has disabled, and calls naming a protocol method we do not implement. Each of those is the server behaving correctly in response to a request it should refuse, so counting them as failures would describe working software as broken. Counting them as successes would pad the figure instead. They are reported separately above as “declined by design” so you can see their volume and recompute the rate however you prefer.

Malformed tool calls. We also exclude calls an AI assistant made with arguments that do not fit the tool's published schema — a required field left out, a value of the wrong type. We check arguments before we call anything, so these are rejected by us, in a fraction of a millisecond, without the provider being contacted; they tell you what the assistant asked for, not whether our service was working. This is the same judgement we already make about a call naming a method we do not implement, and we apply it just as narrowly: a call only qualifies if its recorded error is the exact message our own validator writes for the exact tool that was called. An error relayed from a provider cannot fall into this bucket. The count is printed above as “rejected as malformed”, separately from the other declines, so you never have to take our word for the effect. Counting every one of them as a failure instead, the last 7 days would read 90.7% rather than 91.2%.

What counts as a failure. Everything else that errored, including errors that came back from the third-party API we were calling on a customer's behalf — an expired credential, a missing permission scope, a provider rate limit, a provider timeout, a query the assistant wrote that the provider's own schema rejected. Those are not always our fault, and we have not tried to separate out the ones that are. The published rate is therefore a floor on our own reliability, not a flattering reading of it.

Where the thresholds sit. We call the endpoint operational at 95% and above, degraded from 85% to 95%, and an outage below 85%. Those are lower than a status page for a single self-contained service would use, for two reasons we would rather state than bury. The first is the paragraph above: the denominator carries other companies' failures as well as ours, so a bar set where a platform-only measurement would sit is being applied to a number that is not measuring only the platform. The second is volume. At the 172 calls we served in the last 7 days, one failure moves the rate by 0.58 points, and a threshold with less than a few failures of headroom underneath it would flip this banner on noise. What these thresholds are not is a bar set wherever this week's number happened to land: they were chosen against what the measurement contains and how much of it there is, and the banner above is whatever applying them produces. The exact rate and the exact counts are printed above, so if your bar is higher than ours, those are the numbers to apply it to.

Scope, and what is missing. These figures are derived only from MCP requests that reached our application and were logged. A period in which the server was completely unreachable would leave no rows behind and would be invisible here. That is a real limitation: this is a service-health measurement, not an uptime measurement, and we do not publish an uptime percentage because we do not yet run the external monitoring that would be needed to compute one honestly. Windows are rolling, relative to when you loaded this page.

No SLA. Serve MCP does not offer a service level agreement, and nothing on this page is a commitment or a target. It is a record of what actually happened.

There is also a machine-readable probe at /api/health, which reports database reachability and returns a non-200 status when it fails. If something looks wrong that this page does not reflect, tell us.