Skip to main content

​
Hosted monitoring

The fastest path: sign in at mcpcomp.dev — email, Google, or GitHub — and add a server URL in the dashboard. The first scan becomes its baseline; every server is rescanned daily, and when the authentication configuration drifts you get an email, a Slack message if you paste an Incoming Webhook URL on the account page, and, if you bind a repository through the MCPComp GitHub App, a labelled issue plus a pull request committing the post-drift report — so accepting drift is a reviewable diff, and merging it closes the issue. Two things the monitor deliberately does not page you for. When the scanner itself is upgraded and starts observing a field the baseline never carried, that is an introduction, not drift: the baseline advances silently and the report lists the new fields under “newly observed”. And when a run cannot complete for a server — the scan threw, or no alert channel could deliver — the dashboard shows Monitoring degraded with the reason next to that server (a revoked GitHub App installation reads “reconnect GitHub”) until a run completes; a daily scan that throws is never mistaken for a quiet one. The free plan monitors one server. Pro monitors up to ten at 30/seat/monthbilledannually(30/seat/month billed annually (38 monthly).

​
Plan limits

Limits apply at scan time, not only when a server is added: a downgraded account keeps its oldest servers up to the plan’s limit and the rest pause, shown as such on the dashboard, until a server is removed or the plan upgraded.

​
Save a baseline, compare later

In CI, add --junit report.xml to either command to get the same verdict as JUnit XML — one test case per check, a requirement violation as a failure, an advisory as a pass carrying its message, a skipped check as skipped, an inconclusive scan as one error case carrying the reason — so the run’s test-report view shows which check failed without reading the log. The scan GitHub Action exposes it as the junit input.
The diff compares the facts a verdict depends on, not the raw report — otherwise every run would “change” its own timestamp and HTTP observations. Scope lists compare as sets; version lists stay order-sensitive because their order is preference.

​
Continuous monitoring in your own repository

Prefer to run it yourself? List servers in monitor/targets.txt, one URL per line. A scheduled workflow scans each daily against committed baselines and, when the authentication configuration moves:
  1. Fails the run, with the changed fields in the job summary.
  2. Opens a labelled issue, which notifies through whatever you already have GitHub notifications wired to — email, mobile push. When the scan matches the baselines again, the issue closes itself.
  3. Opens a pull request with the new baseline, so accepting drift is a reviewable diff a human merges — not a silent push. The baseline is written only when the scan produced a valid graded report, so an inconclusive or failed run never overwrites a trusted reference.
There is no scheduler and no database: cron already exists, and keeping baselines in the repository means every change is attributable.

​
What it alerts on

  • A field disappeared from the metadata
  • The issuer changed
  • code_challenge_methods_supported dropped
  • An endpoint moved to a different host — the change that matters most, since credentials are sent to it, and nothing else about the metadata need change
  • The server stopped requiring authorization, or started redirecting
For the one failure no probe can see coming — a credential expiring inside the identity provider — see Microsoft Entra.