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 95.8% rather than 95.8%.

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.

How the banner decides. It does not use the rates above. A rolling average answers “how has the last week gone”, which is not what you came here to ask, and it is wrong in both directions: a bad hour keeps a recovered service amber for days afterwards, and a failure a minute ago vanishes into a week of successes. Instead we look at the tail of the log — the most recent 12 served calls — and count how many failed consecutively before the first success. 2 in a row reads as degraded, 4 as an outage. A run of failures is the shape an incident actually has; a percentage is not. If nothing has been served for three days we stop claiming to know, and say so, rather than reporting a stale success as current health.

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.