The tracker as an MCP server

Everything on these pages is also readable by an MCP client, so you can ask a model about a certificate instead of searching for one. Read only, no key, no account.

https://fips.808bits.com/mcp

In Claude Code:

claude mcp add --transport http fips https://fips.808bits.com/mcp

Anywhere that takes the usual JSON:

{
  "mcpServers": {
    "fips": {
      "type": "http",
      "url": "https://fips.808bits.com/mcp"
    }
  }
}

The endpoint speaks POST. Opening it in a browser will not show you anything.

What it answers

Six tools. fips_cert takes a certificate number and returns the status, level, sunset date and the validation history this tracker derives. fips_search looks for a vendor or product across all 5,504 certificates. fips_vendor returns everything one company holds. fips_sunset lists what expires before a date you give it. fips_cve maps between certificates and CVE identifiers.

The one with no equivalent anywhere else is fips_in_process. NIST publishes the modules-in-process queue as a web page and nothing else, so “it is on MIP” is normally something you check by hand, usually at the point where a validation has lapsed and somebody wants to know whether the replacement is coming.

Every result carries a link back to the certificate page here, because a tool response is a summary and the page has the caveats the summary dropped.

What it will get wrong if you let it

A model reading this data will state things more confidently than the data supports. Three places that matters.

A submission in the queue is a milestone, not a date. 181 modules are in process and some have sat in one phase for over a year. The phase says review started, not when it ends.

An absence from the queue can mean the replacement already landed. Ribbon’s SBC 5400 sunsets on 2026-09-06 and has held a 140-3 certificate since 2025. It is not in the queue because it does not need to be. Search the module name before reporting a gap.

A CVE result, in either direction, is a name match. The association comes from the vendor and product CPE, so a listed CVE may sit in code the certificate never covered. The empty answer is the more misleading one: 16 certificates out of 5,504 carry any CVE association at all, the match does not follow dependencies, and hardware modules almost never match. Asking about an HSM vendor and getting nothing back says something about CPE naming and nothing about the module. How the matching works covers the bar a pair has to clear.

The server repeats these three in its own responses rather than relying on anyone having read this page.

Where the answers come from

The same snapshots that build these pages, loaded into a database the server reads. It does not fetch anything from NIST while answering, so responses are as fresh as the last refresh and every one of them carries the generation date. Nothing you ask is logged against you, and there is nothing to log in to.