Skip to main content
Everything else on the overview is a number. Insights are the part that says what the number means and what it costs. Every insight carries a tool name, a figure, and a consequence. An insight without a number is not an insight — it is a horoscope.

​
The five rules

These thresholds are constants in one service, and the tool health badges read the same ones — so the table cannot say a tool is healthy while the panel beneath it says otherwise.

​
Twenty calls minimum

No rule fires on a tool with fewer than 20 calls in range. Two empties out of three calls is 67% and means nothing. Publishing it teaches authors to distrust the panel, and a panel nobody trusts is worse than no panel. The low first-call rule applies the same floor to its nightly call count specifically, since that is its real denominator.

​
Severity and ordering

Each rule has a threshold at which it escalates: Insights are sorted by severity first, then by the size of the figure that fired them. So the worst instance of the worst class is at the top, which is where to start.

​
What is deliberately not here

  • No insight without a tool name. “Your server is slow” is not actionable.
  • No insight without a figure. The number is what makes it arguable, and arguable is what makes it useful.
  • No trend-only insights. A metric that moved is on the card, with its delta. An insight is a statement about a threshold being crossed.

​
Where they appear

On the overview, in the insights panel. Over the API at GET /v1/mcps/{id}/insights. And through the get_insights MCP tool, which is the one to reach for when someone asks how their server is doing rather than for a specific figure. All three read the same service, so all three say the same thing.

​
First-call insights lag a day

The low first-call rule reads a metric computed by the nightly pass and only fires on days it has covered. Without that restriction every tool would be reported as broken every morning until 02:00. The other four rules are live.