Contribute

Add what you know, with evidence

The atlas is a dataset in a git repository. Anyone can add an observation or correct one; a maintainer reviews the evidence before it is published. Nothing is ever edited in place.

Two ways in

Pick the one that fits what you have. Both end in a reviewed pull request, and the result looks the same in the atlas.

  • Path A

    Open an issue

    The quickest route. The form asks for the same fields as a data entry: server, feature, revision, status, method, date, evidence and your handle. A maintainer turns an accepted issue into a pull request and links the issue as evidence where the issue itself is the evidence.

    Open the issue form

  • Path B

    Open a pull request

    Append an entry to the server's observation file yourself. Validation runs locally and again in CI, so a reviewer only has to open the evidence. The steps are below.

    Open the repository

The pull request, step by step

  1. Append an entry to data/observations/<server-id>.yaml. Create the file if the server has none.
  2. Run pnpm validate:data. Failures name the file, the entry index and the field, for example data/observations/stripe.yaml[3].evidence: required (URL or note).
  3. Open the pull request. CI repeats the validation and the append-only check.
  4. A maintainer reviews the evidence and merges. The next deploy publishes it.

Entry format

- server: stripe                     # must equal the file's server id
  feature: mcp.as.cimd               # a feature with party mcp-server or authorization-server
  revision: { spec: mcp-authorization, revision: "2026-07-28" }
  status: supported                  # supported | partial | unsupported | unknown | not-applicable
  method: passive-scan               # manual | vendor-claim | passive-scan | active-scan
  observedAt: 2026-10-13T18:40:00Z
  observedBy: jbspeakr               # your handle, or scanner@<version>
  evidence: https://auth.stripe.com/.well-known/oauth-authorization-server

Evidence is a URL a reviewer can open (a metadata document, a documentation page, a response capture) or a precise note. Method says how you know: manual for something you checked by hand,vendor-claim for what the vendor says, passive-scan for reading public metadata, active-scan for sending requests. When two observations of a cell exist, the newest one is shown; equal timestamps are broken by method strength (active-scan over passive-scan over manual over vendor-claim).

Let the scanner write it

For the 14 requirements the passive scanner can read from public metadata, prefer pnpm scan <server-id> --write over a hand-written entry. It appends exactly the observations whose status or evidence changed, with evidence anyone can reproduce by running the same command. The nightly run does the same for every listed server and opens its own pull request.

The append-only rule

Observations are never edited or removed

A correction is a new entry with a newer observedAt; the old one stays in the history on the server page. CI fails any pull request that changes or deletes an existing entry.

Listing a server

Add data/servers/<id>.yaml with the endpoint, transport andlisted. If you maintain the server, use listed: opt-in; otherwise give the source that lists it publicly. Servers are listed as they appear in public directories; nobody is scored or ranked.

Withdrawing a server

If you maintain a server and do not want it listed, use the issue form with "withdraw my server" and a way to verify that you maintain it. A pull request then setswithdrawn on the server. It leaves the matrix and the export; its observations stay in the repository history.

Licences

Data you contribute is published under CC BY 4.0; the site's code is MIT.