API

Stable, documented, free. No key, no cookie, no rate limit worth mentioning. If you are an agent, this is the endpoint you want.

`GET /api/scores.json`

The full dataset and the single source of truth for this site. Every page here derives from it; if a page and this file disagree, the file is right and the page is a bug.

{
  "version": "1.0",
  "generated": "<ISO 8601 UTC>",
  "build_id": "<release id>",
  "coverage": "<denominator statement>",
  "servers": [
    {
      "name": "<registry package identifier>",
      "class": "scored" | "auth-required" | "insufficient-coverage",
      "life_state": "alive" | "ailing" | "dead" | null,
      "run_id": "<fleet run id>",
      "last_probed": "<ISO 8601 UTC>",
      "axes": { "<axis id>": true | false | null },
      "adversarial_self_identified": true | false,
      "coverage_failure": "<reason>" | null
    }
  ]
}

Freshness and priority coverage

freshness is the canonical status object shared with the home and directory pages. It contains generated_at, latest_successful_measurement_at (or null), freshness_age_hours (or null), freshness_state (fresh, stale, halted, unknown), campaign_state (running, blocked, degraded, complete, unknown), priority_cohort (total, fresh, coverage_pct, unknown_target_ids, members), and message. freshness_sla_hours defaults to 36. This is a static snapshot evaluated at generated_at; consumers must recompute age at retrieval. A newly generated file does not mean newly measured targets. An incomplete priority cohort cannot be fresh because a long-tail target was recently measured. Candidate totals remain in summary.

Each server adds measurement: last_verified_at, last_verified_run_id, freshness_age_hours, freshness_state, failed_phase, observations, and up to five history entries with timestamp, run_id, life_state, classification. Observations are pass, fail, or not measured. Missing observations never imply failure. Historical results do not promise that a target remains operational now.

`GET /api/changes.json`

Up to 100 deterministic change entries compare the latest valid run with its immediately preceding valid run per real target. Fields: target, kind, event_at, timestamp, run_id, previous_timestamp, previous_run_id, from_state, to_state. A first measurement has null previous fields. Kinds: newly_measured, failure, recovered, newly_auth_required, newly_insufficient_coverage, freshness_expired. Expiry is derived metadata and uses the latest measurement plus the SLA. The feed also contains generated_at, total_changes, and diagnostics. Empty changes is valid; this is a snapshot, not a durable event queue.

`GET /api/analytics-status.json`

Non-blocking analytics status: never_ingested, fresh, stale, failed, with last_success and last_attempt timestamps. Local paths and failure details are not public.

What a life-state means

These are liveness measurements, not safety assessments. A server marked alive installed, started, completed an MCP handshake and listed its tools. It has not been audited for security or correctness. Adversarial tooling is measured and tagged rather than excluded.

Stability contract

Fields are added, never removed or repurposed, without a version bump.
run_id always identifies a real fleet run. Cite it.
unmeasured is never collapsed into dead. An absent measurement is not a verdict.
Aggregate numeric scores are currently suppressed pending rubric v1.1. Please do not synthesize one from the axes — the weighting is exactly what is under revision.

MCP server (read-only, unauthenticated)

Deaddit also publishes its dataset as a read-only MCP (Model Context Protocol) server so agent clients can query live data directly. The server is reachable at https://deaddit.top/mcp and exposes four tools:

Tool	Description
`check_server`	Look up a server by package name. Returns life-state, run_id, last_probed, axes, adversarial tag.
`list_by_state`	List servers by life-state: alive, ailing, dead, auth_required, insufficient_coverage, unmeasured.
`latest_necropsy`	Return the latest Necropsy editorial findings summary.
`methodology`	Return the scoring methodology and disclosure.

The server is rate-limited (60 requests/minute per IP), loopback-only on the VPS, serves the same scores.json dataset, and performs no writes or state mutation. JSON-RPC 2.0 over HTTP clients can connect directly. Reuse: the scores.json API and the MCP server are licensed for retrieval and citation under CC-BY-4.0. Any claim must trace to a run_id; cite it.

Other endpoints

/feed.xml — RSS for the Necropsy
/llms.txt — orientation for retrieval systems
/sitemap.xml — all pages

← Deaddit